{"id": "syn-5", "cat": "smalltalk", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-03-08", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-03-08. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Thank you for finding that EU report on heat pumps, my landlord finally took me seriously after I showed him the numbers."}, {"role": "assistant", "content": "{\"standalone_question\": \"Thank you for finding the EU report on heat pumps; my landlord took me seriously after I showed him the numbers.\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": false, \"search_queries\": [], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-10", "cat": "smalltalk", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-10-16", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-10-16. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Thanks, that was super helpful. Same time tomorrow?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Same time tomorrow?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": false, \"search_queries\": [], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-31", "cat": "smalltalk", "lang": "de", "settings": {"depth": "deep", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-07-11", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-07-11. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Ich hab morgen Abi-Prüfung in Geschichte und mein Kopf ist leer. Kannst du mir was zum Dreißigjährigen Krieg erklären? Wie hat der eigentlich angefangen?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Wie hat der Dreißigjährige Krieg angefangen? Welche Ursachen und Auslöser führten zu Beginn 1618 zum Krieg?\", \"answer_shape\": \"explainer\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Dreißigjähriger Krieg Ursachen Beginn 1618 Prager Fenstersturz\", \"Dreißigjähriger Krieg Auslöser Konfessionskonflikt Reichsverfassung\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [\"reference\", \"web\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-54", "cat": "transform", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-06-14", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-06-14. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Could you turn this into a bulleted list for my slides? \"The Meiji Restoration of 1868 ended the Tokugawa shogunate. It modernized Japan's military, education system, and economy. Western technology and legal models were widely adopted.\""}, {"role": "assistant", "content": "{\"standalone_question\": \"Turn the following pasted text into a bulleted list for slides: \\\"The Meiji Restoration of 1868 ended the Tokugawa shogunate. It modernized Japan's military, education system, and economy. Western technology and legal models were widely adopted.\\\"\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": false, \"search_queries\": [], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-55", "cat": "transform", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-11-15", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-11-15. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Would you be able to translate this into French? I need it for a museum label: \"This vase, produced in Athens around 490 BCE, depicts warriors preparing for battle and was used in ceremonial feasts.\""}, {"role": "assistant", "content": "{\"standalone_question\": \"Translate into French: \\\"This vase, produced in Athens around 490 BCE, depicts warriors preparing for battle and was used in ceremonial feasts.\\\"\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": false, \"search_queries\": [], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-57", "cat": "transform", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-01-29", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-01-29. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Could you reformat this as a short APA-style citation? \"Hobsbawm, E. (1994). The Age of Extremes: The Short Twentieth Century, 1914-1991. Michael Joseph, London.\""}, {"role": "assistant", "content": "{\"standalone_question\": \"Reformat this citation as a short APA-style citation: Hobsbawm, E. (1994). The Age of Extremes: The Short Twentieth Century, 1914-1991. Michael Joseph, London.\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": false, \"search_queries\": [], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-65", "cat": "transform", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["reference"], "auto_lenses": false, "library": false, "web": true, "date": "2026-07-04", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Reference: Name the subject as an encyclopaedia would title its article: the bare concept, without question words.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-07-04. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Please condense this into a single sentence for my flashcard: \"The Hanseatic League was a commercial and defensive confederation of merchant guilds and market towns in northern Europe, flourishing from the thirteenth to the seventeenth centuries and dominating Baltic trade.\""}, {"role": "assistant", "content": "{\"standalone_question\": \"Please condense this into a single sentence for my flashcard: \\\"The Hanseatic League was a commercial and defensive confederation of merchant guilds and market towns in northern Europe, flourishing from the thirteenth to the seventeenth centuries and dominating Baltic trade.\\\"\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": false, \"search_queries\": [], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-129", "cat": "transform", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-03-12", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-03-12. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Könnten Sie diesen Satz bitte in einfaches Deutsch umschreiben? \"Die Kapitalertragsteuer wird unabhängig vom persönlichen Einkommensteuersatz pauschal mit 25 Prozent zuzüglich Solidaritätszuschlag erhoben.\""}, {"role": "assistant", "content": "{\"standalone_question\": \"Bitte den Satz \\\"Die Kapitalertragsteuer wird unabhängig vom persönlichen Einkommensteuersatz pauschal mit 25 Prozent zuzüglich Solidaritätszuschlag erhoben.\\\" in einfaches Deutsch umschreiben.\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": false, \"search_queries\": [], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-138", "cat": "transform", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-11-14", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-11-14. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Kannst du mir das kurz erklären und zusammenfassen? \"Ein ETF bildet einen Börsenindex nach. Er ist kostengünstig, breit gestreut und wird meist passiv verwaltet, was ihn für langfristige Anleger attraktiv macht.\""}, {"role": "assistant", "content": "{\"standalone_question\": \"Erkläre und fasse kurz zusammen: Ein ETF bildet einen Börsenindex nach. Er ist kostengünstig, breit gestreut und wird meist passiv verwaltet, was ihn für langfristige Anleger attraktiv macht.\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": false, \"search_queries\": [], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-150", "cat": "transform", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-05-07", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-05-07. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Bitte übersetze das ins Italienische: \"Ich möchte wissen, ob sich ein Wechsel zu einem Online-Broker für mich lohnt, wenn ich nur einmal im Monat einen kleinen Betrag investiere.\""}, {"role": "assistant", "content": "{\"standalone_question\": \"Bitte übersetze das ins Italienische: \\\"Ich möchte wissen, ob sich ein Wechsel zu einem Online-Broker für mich lohnt, wenn ich nur einmal im Monat einen kleinen Betrag investiere.\\\"\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": false, \"search_queries\": [], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-151", "cat": "arithmetic", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-02-28", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-02-28. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "if i have 3 potions at 45 gold each and sell them at 1.15x, whats the total gold i get"}, {"role": "assistant", "content": "{\"standalone_question\": \"If I have 3 potions that cost 45 gold each and I sell them at 1.15x their cost, what is the total gold I receive?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": false, \"search_queries\": [], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-171", "cat": "arithmetic", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["web", "news"], "auto_lenses": false, "library": false, "web": true, "date": "2027-07-11", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n- News: Name the event, the organisation and the period being asked about.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-07-11. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "hp regen of 3.5 per sec, how long to heal 490 hp"}, {"role": "assistant", "content": "{\"standalone_question\": \"With a regeneration rate of 3.5 HP per second, how long does it take to heal 490 HP?\", \"answer_shape\": \"figure\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": false, \"search_queries\": [], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-172", "cat": "arithmetic", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["web", "news"], "auto_lenses": false, "library": false, "web": true, "date": "2026-10-15", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n- News: Name the event, the organisation and the period being asked about.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-10-15. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "convert 0.75 cups to tablespoons"}, {"role": "assistant", "content": "{\"standalone_question\": \"Convert 0.75 cups to tablespoons\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": false, \"search_queries\": [], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-178", "cat": "arithmetic", "lang": "de", "settings": {"depth": "quick", "queries": 2, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-10-05", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 2 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-10-05. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Rechne mir bitte 3/8 Zoll in Millimeter um, ich brauche den Bohrer für eine Gewindestange."}, {"role": "assistant", "content": "{\"standalone_question\": \"Wie viele Millimeter sind 3/8 Zoll?\", \"answer_shape\": \"figure\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": false, \"search_queries\": [], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-213", "cat": "code", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-01-26", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-01-26. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "wait is it true that sharks don't get cancer? saw it on tiktok\n\nthat's the claim I saw in a video, source says 'sharks have cartilage so no tumors'"}, {"role": "assistant", "content": "{\"standalone_question\": \"Is it true that sharks don't get cancer because they have cartilage instead of bone?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"sharks cancer tumors incidence cartilage myth\", \"shark tumor cases pathology study\", \"cartilage tumor-free claim sharks evidence\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [\"web\", \"scholar\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-235", "cat": "code", "lang": "en", "settings": {"depth": "deep", "queries": 3, "sources": ["reference"], "auto_lenses": false, "library": false, "web": true, "date": "2027-09-23", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Reference: Name the subject as an encyclopaedia would title its article: the bare concept, without question words.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-09-23. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "whats the diff between these two rows from my sleep tracker, why does deep sleep drop but the total goes up\n\nnight  total_min  deep_min  rem_min\n04-10  412        61        88\n04-11  447        38        102"}, {"role": "assistant", "content": "{\"standalone_question\": \"Between nights 04-10 and 04-11 in my sleep tracker data (total 412 min, deep 61 min, REM 88 min on 04-10; total 447 min, deep 38 min, REM 102 min on 04-11), why does deep sleep drop while total sleep goes up?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": false, \"search_queries\": [], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-267", "cat": "code", "lang": "de", "settings": {"depth": "deep", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-10-27", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-10-27. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Ich wollte eine Wand streichen und habe folgende Tabelle für den Materialbedarf gefunden:\nFläche m²: 10 | Verbrauch l/m²: 0,15\nFläche m²: 20 | Verbrauch l/m²: 0,15\nWie viel Farbe brauche ich ungefähr für 14 m²?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Wie viel Farbe brauche ich ungefähr für 14 m² Wand, wenn der Verbrauch 0,15 l/m² beträgt?\", \"answer_shape\": \"figure\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": false, \"search_queries\": [], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-284", "cat": "code", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["scholar"], "auto_lenses": false, "library": false, "web": true, "date": "2027-08-04", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Science: Write these in English whatever language the question is in: Crossref, arXiv, OpenAlex and PubMed index English titles and abstracts, and a German query returns whatever happened to share a word with it. Use the field's own terminology and name the population, intervention or mechanism. These are bibliographic databases, not a search box.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-08-04. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Kurze Frage von meinem Bruder der Physik studiert: Warum kommt bei diesem Python-Code immer 0.1 + 0.2 != 0.3 raus?\n\nprint(0.1 + 0.2 == 0.3)\nprint(0.1 + 0.2)"}, {"role": "assistant", "content": "{\"standalone_question\": \"Warum gibt Python für 0.1 + 0.2 nicht exakt 0.3 zurück, und warum ergibt print(0.1 + 0.2 == 0.3) False?\", \"answer_shape\": \"explainer\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": false, \"search_queries\": [], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-344", "cat": "figure", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["scholar"], "auto_lenses": false, "library": false, "web": true, "date": "2026-09-20", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Science: Write these in English whatever language the question is in: Crossref, arXiv, OpenAlex and PubMed index English titles and abstracts, and a German query returns whatever happened to share a word with it. Use the field's own terminology and name the population, intervention or mechanism. These are bibliographic databases, not a search box.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-09-20. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Current US unemployment rate, the most recent BLS release"}, {"role": "assistant", "content": "{\"standalone_question\": \"What is the current US unemployment rate in the most recent BLS release?\", \"answer_shape\": \"figure\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"BLS current unemployment rate latest release\", \"US unemployment rate Bureau of Labor Statistics Employment Situation 2026\"], \"recency\": \"month\", \"complexity\": \"simple\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-346", "cat": "figure", "lang": "en", "settings": {"depth": "quick", "queries": 2, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-01-26", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 2 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-01-26. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Current population of Lagos, Nigeria per the most recent UN estimate"}, {"role": "assistant", "content": "{\"standalone_question\": \"What is the current population of Lagos, Nigeria according to the most recent United Nations estimate?\", \"answer_shape\": \"figure\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Lagos population United Nations World Urbanization Prospects 2025\", \"Lagos Nigeria population estimate UN latest\"], \"recency\": \"year\", \"complexity\": \"simple\", \"lenses\": [\"data\", \"web\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-349", "cat": "figure", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["scholar"], "auto_lenses": false, "library": false, "web": true, "date": "2026-04-23", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Science: Write these in English whatever language the question is in: Crossref, arXiv, OpenAlex and PubMed index English titles and abstracts, and a German query returns whatever happened to share a word with it. Use the field's own terminology and name the population, intervention or mechanism. These are bibliographic databases, not a search box.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-04-23. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "What's the current number of public EV charging points in the Netherlands, per RVO or the latest count?"}, {"role": "assistant", "content": "{\"standalone_question\": \"What is the current number of public EV charging points in the Netherlands, according to RVO or the latest count?\", \"answer_shape\": \"figure\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"RVO public charging points Netherlands number 2026\", \"Netherlands public EV charging points count laadpunten aantal\", \"laadpunten Nederland aantal openbaar RVO laadpalen\"], \"recency\": \"year\", \"complexity\": \"simple\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-360", "cat": "figure", "lang": "de", "settings": {"depth": "quick", "queries": 2, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-04-29", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 2 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-04-29. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "welchen zinssatz bietet die dkb fuer tagesgeld aktuell"}, {"role": "assistant", "content": "{\"standalone_question\": \"Welchen Zinssatz bietet die DKB aktuell für Tagesgeld?\", \"answer_shape\": \"figure\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"DKB Tagesgeld Zinssatz aktuell\", \"DKB Tagesgeld Konditionen 2026\"], \"recency\": \"year\", \"complexity\": \"simple\", \"lenses\": [\"web\", \"data\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-399", "cat": "figure", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-09-10", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-09-10. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Wie hoch ist der Verbraucherpreisindex für Deutschland im letzten veröffentlichten Monat?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Wie hoch ist der Verbraucherpreisindex für Deutschland im letzten veröffentlichten Monat?\", \"answer_shape\": \"figure\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Verbraucherpreisindex Deutschland letzter Monat Destatis\", \"VPI Deutschland Inflationsrate aktuell\"], \"recency\": \"month\", \"complexity\": \"simple\", \"lenses\": [\"data\", \"web\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-403", "cat": "figure", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-08-12", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-08-12. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Wie viele Kilometer Autobahn hat Deutschland aktuell insgesamt?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Wie viele Kilometer Autobahn hat Deutschland aktuell insgesamt?\", \"answer_shape\": \"figure\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Autobahnnetz Deutschland Gesamtlänge km 2026\", \"Länge Autobahnnetz Deutschland aktuell Bundesanstalt für Straßenwesen\"], \"recency\": \"year\", \"complexity\": \"simple\", \"lenses\": [\"data\", \"reference\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-458", "cat": "fact", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["web", "scholar"], "auto_lenses": false, "library": false, "web": true, "date": "2026-10-21", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n- Science: Write these in English whatever language the question is in: Crossref, arXiv, OpenAlex and PubMed index English titles and abstracts, and a German query returns whatever happened to share a word with it. Use the field's own terminology and name the population, intervention or mechanism. These are bibliographic databases, not a search box.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-10-21. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "welche stadt ist die hauptstadt von australien echt, ich dachte immer canberra stimmt das"}, {"role": "assistant", "content": "{\"standalone_question\": \"Ist Canberra die Hauptstadt von Australien?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Hauptstadt Australien Canberra\", \"capital of Australia Canberra\"], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-474", "cat": "fact", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-02-04", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-02-04. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "wo wurde die sparkasse zum ersten mal gegründet"}, {"role": "assistant", "content": "{\"standalone_question\": \"In welcher Stadt wurde die Sparkasse zum ersten Mal gegründet?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"erste Sparkasse Gründung Geschichte\", \"Hamburgische Spar-Casse 1778 erste Sparkasse Deutschland\"], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [\"reference\", \"web\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-478", "cat": "fact", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["docs"], "auto_lenses": false, "library": false, "web": true, "date": "2027-08-11", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Docs & code: Name the exact API, error message, version or package.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-08-11. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Wir fahren im Sommer mit den Kindern nach Island, wie hoch ist eigentlich der Hvannadalshnúkur?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Wie hoch ist der Hvannadalshnúkur?\", \"answer_shape\": \"figure\", \"place\": \"\", \"wants_image\": true, \"image_query\": \"Hvannadalshnúkur\", \"needs_search\": true, \"search_queries\": [\"Hvannadalshnúkur Höhe Meter\", \"Hvannadalshnúkur height metres highest peak Iceland\"], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-484", "cat": "fact", "lang": "de", "settings": {"depth": "quick", "queries": 2, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-06-15", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 2 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-06-15. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Meine Oma kommt aus Ostpreußen und ich wollte wissen wie die Stadt Königsberg heute heißt und in welchem Land sie liegt."}, {"role": "assistant", "content": "{\"standalone_question\": \"Wie heißt die Stadt Königsberg heute und in welchem Land liegt sie?\", \"answer_shape\": \"profile\", \"place\": \"\", \"wants_image\": true, \"image_query\": \"Kaliningrad\", \"needs_search\": true, \"search_queries\": [\"Königsberg heute Kaliningrad Land\", \"Kaliningrad Oblast Russland Geschichte Königsberg Ostpreußen\"], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [\"reference\", \"web\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-487", "cat": "fact", "lang": "de", "settings": {"depth": "deep", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-01-14", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-01-14. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Wer war der erste Mensch im Weltraum und in welchem Jahr war das?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Wer war der erste Mensch im Weltraum und in welchem Jahr war das?\", \"answer_shape\": \"profile\", \"place\": \"\", \"wants_image\": true, \"image_query\": \"Yuri Gagarin\", \"needs_search\": true, \"search_queries\": [\"erster Mensch im Weltraum Gagarin Jahr\", \"first human in space Yuri Gagarin 1961 Vostok 1\"], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [\"reference\", \"web\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-492", "cat": "fact", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-09-07", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-09-07. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Wer hat eigentlich die Glühbirne erfunden, Edison oder jemand anderes?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Wer hat die Glühbirne erfunden: Thomas Edison oder jemand anderes?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Erfindung Glühbirne Edison Joseph Swan Geschichte\", \"wer hat die Glühbirne erfunden\", \"incandescent light bulb history inventors Edison Swan Lodygin\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [\"reference\", \"web\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-564", "cat": "weather", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-02-24", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-02-24. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Could you check whether it's going to be windy in Dublin tomorrow? I'm flying out in the morning and worried about delays."}, {"role": "assistant", "content": "{\"standalone_question\": \"Will it be windy in Dublin tomorrow, 25 February 2027, and could the wind cause morning flight delays at Dublin Airport?\", \"answer_shape\": \"weather\", \"place\": \"Dublin\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Dublin weather forecast tomorrow wind\", \"Dublin Airport wind flight delays forecast\", \"Met Eireann Dublin wind warning\"], \"recency\": \"day\", \"complexity\": \"simple\", \"lenses\": [\"web\", \"data\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-567", "cat": "weather", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-01-04", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-01-04. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "How cold will it get in Montreal tonight? My car battery died last winter and I'm worried about the cold."}, {"role": "assistant", "content": "{\"standalone_question\": \"How cold will it get in Montreal tonight (2027-01-04)?\", \"answer_shape\": \"weather\", \"place\": \"Montreal\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Montreal weather tonight forecast\", \"Montreal overnight low temperature forecast\"], \"recency\": \"day\", \"complexity\": \"simple\", \"lenses\": [\"web\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-582", "cat": "weather", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-06-11", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-06-11. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Muss morgen früh um 6 nach München zum Flughafen, ist Glätte auf der A9 zu erwarten?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Ist morgen früh um 6 Uhr mit Glätte auf der A9 Richtung Flughafen München zu rechnen?\", \"answer_shape\": \"weather\", \"place\": \"München\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Glätte A9 München Flughafen morgen früh\", \"Wetter München morgen früh Frost Glatteis\"], \"recency\": \"week\", \"complexity\": \"simple\", \"lenses\": [\"web\", \"data\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-606", "cat": "match", "lang": "en", "settings": {"depth": "quick", "queries": 2, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-12-08", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 2 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-12-08. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "whats the next fixture for real madrid in the league"}, {"role": "assistant", "content": "{\"standalone_question\": \"What is Real Madrid's next La Liga fixture?\", \"answer_shape\": \"match\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Real Madrid next La Liga match\", \"Real Madrid La Liga fixtures 2026-27\"], \"recency\": \"year\", \"complexity\": \"simple\", \"lenses\": [\"web\", \"news\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-631", "cat": "match", "lang": "de", "settings": {"depth": "quick", "queries": 2, "sources": ["web", "data"], "auto_lenses": false, "library": false, "web": true, "date": "2027-01-28", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 2 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n- Data: Name the quantity the way a calculator would take it (`AAPL stock price`, `100 USD in EUR`, `population of Berlin`), not as a sentence.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-01-28. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Kann mir jemand sagen wer am Wochenende gegen wen spielt in der 2. Bundesliga?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Welche Spiele finden am kommenden Wochenende (30./31. Januar 2027) in der 2. Bundesliga statt, also wer spielt gegen wen?\", \"answer_shape\": \"table\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"2. Bundesliga Spieltag Wochenende Spielplan\", \"2. Bundesliga Spieltag Januar 2027 Ansetzungen\"], \"recency\": \"week\", \"complexity\": \"simple\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-641", "cat": "match", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-09-06", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-09-06. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Wie viele Gelbe Karten hat Robert Andrich dieses Jahr bekommen?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Wie viele Gelbe Karten hat Robert Andrich im Jahr 2026 bekommen?\", \"answer_shape\": \"figure\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Robert Andrich gelbe Karten 2026\", \"Robert Andrich yellow cards 2026 season\"], \"recency\": \"year\", \"complexity\": \"simple\", \"lenses\": [\"web\", \"data\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-651", "cat": "match", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-10-04", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-10-04. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Kannst du mir die Tore vom Spiel Hoffenheim gegen Augsburg vom Mittwoch aufzählen?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Welche Tore fielen im Spiel TSG Hoffenheim gegen FC Augsburg am Mittwoch?\", \"answer_shape\": \"match\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Hoffenheim Augsburg Tore Spielbericht\", \"Hoffenheim Augsburg Bundesliga Ergebnis Torschützen\"], \"recency\": \"week\", \"complexity\": \"simple\", \"lenses\": [\"news\", \"web\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-657", "cat": "standings", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-02-01", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-02-01. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "top selling electric cars in europe last year ranking pls"}, {"role": "assistant", "content": "{\"standalone_question\": \"What were the top-selling electric cars in Europe in 2025, ranked by registrations?\", \"answer_shape\": \"table\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"best-selling electric cars Europe 2025 ranking\", \"Europe BEV registrations 2025 by model\"], \"recency\": \"year\", \"complexity\": \"standard\", \"lenses\": [\"web\", \"data\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-669", "cat": "standings", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-02-10", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-02-10. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "motogp rider standings after the last grand prix"}, {"role": "assistant", "content": "{\"standalone_question\": \"What are the MotoGP rider championship standings after the most recent Grand Prix, as of 2026-02-10?\", \"answer_shape\": \"table\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"MotoGP rider standings after final grand prix 2025\", \"MotoGP championship final standings Valencia 2025\"], \"recency\": \"year\", \"complexity\": \"simple\", \"lenses\": [\"web\", \"news\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-694", "cat": "standings", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-11-28", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-11-28. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "wer hat aktuell die meisten champions league tore in dieser saison"}, {"role": "assistant", "content": "{\"standalone_question\": \"Wer hat aktuell die meisten Champions-League-Tore in der Saison 2026/27?\", \"answer_shape\": \"table\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Champions League 2026/27 Torschützenliste\", \"Champions League top scorers 2026-27\"], \"recency\": \"year\", \"complexity\": \"simple\", \"lenses\": [\"web\", \"news\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-699", "cat": "standings", "lang": "de", "settings": {"depth": "quick", "queries": 2, "sources": ["scholar"], "auto_lenses": false, "library": false, "web": true, "date": "2026-11-26", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 2 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Science: Write these in English whatever language the question is in: Crossref, arXiv, OpenAlex and PubMed index English titles and abstracts, and a German query returns whatever happened to share a word with it. Use the field's own terminology and name the population, intervention or mechanism. These are bibliographic databases, not a search box.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-11-26. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "wie sieht die nba western conference standings gerade aus"}, {"role": "assistant", "content": "{\"standalone_question\": \"Wie sieht die aktuelle Tabelle der NBA Western Conference aus (Stand 26.11.2026)?\", \"answer_shape\": \"table\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"NBA Western Conference standings\", \"NBA standings 2026-27 season Western Conference\"], \"recency\": \"day\", \"complexity\": \"simple\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-754", "cat": "person", "lang": "en", "settings": {"depth": "deep", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-11-18", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-11-18. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "who is dr nina schwalbe the gp who writes about patient care and what's she known for"}, {"role": "assistant", "content": "{\"standalone_question\": \"Who is Dr Nina Schwalbe, the GP who writes about patient care, and what is she known for?\", \"answer_shape\": \"profile\", \"place\": \"\", \"wants_image\": true, \"image_query\": \"Nina Schwalbe\", \"needs_search\": true, \"search_queries\": [\"Dr Nina Schwalbe GP patient care\", \"Nina Schwalbe general practitioner writer\", \"Nina Schwalbe books articles\"], \"recency\": \"year\", \"complexity\": \"simple\", \"lenses\": [\"reference\", \"web\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-766", "cat": "person", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-01-03", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-01-03. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Ich bin Biologiestudentin im dritten Semester und wir hatten heute Charles Darwin im Seminar. Gibt es neuere Forscher, die sich mit seinen Ideen weiterbeschäftigt haben?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Welche neueren Forscherinnen und Forscher haben sich mit den Ideen Charles Darwins weiterbeschäftigt und sie weiterentwickelt?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"extended evolutionary synthesis Darwin modern research\", \"Darwin theory of evolution contemporary evolutionary biology developments\", \"evolvability natural selection recent studies Darwinian theory\"], \"recency\": \"year\", \"complexity\": \"research\", \"lenses\": [\"web\", \"scholar\"], \"facets\": [\"list\"], \"whole_library\": false}"}]}
{"id": "syn-847", "cat": "organisation", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-09-09", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-09-09. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Is Bethesda's Creation Kit for Starfield available on Xbox Series X or only PC, and what's the mod upload limit?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Is Bethesda's Creation Kit for Starfield available on Xbox Series X or only on PC, and what is the mod upload limit?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Starfield Creation Kit Xbox Series X availability\", \"Starfield Creation Club mod upload limit Xbox\"], \"recency\": \"year\", \"complexity\": \"standard\", \"lenses\": [\"web\", \"news\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-863", "cat": "organisation", "lang": "de", "settings": {"depth": "quick", "queries": 2, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-06-17", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 2 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-06-17. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Unser Kleingarten-Verein in Dresden streitet gerade mit dem Vorstand, wie ist eigentlich der Bundesverband Deutscher Gartenfreunde organisiert und haben die Mitglieder Mitspracherecht?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Wie ist der Bundesverband Deutscher Gartenfreunde (BDG) organisiert, und haben die Mitglieder eines Kleingartenvereins in Dresden Mitspracherecht gegenüber dem Vorstand?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Bundesverband Deutscher Gartenfreunde Organisation Aufbau Landesverbände\", \"Kleingartenverein Mitgliederversammlung Vorstand Rechte Bundeskleingartengesetz Sachsen\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [\"web\", \"reference\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-883", "cat": "organisation", "lang": "de", "settings": {"depth": "deep", "queries": 3, "sources": ["web", "docs"], "auto_lenses": false, "library": false, "web": true, "date": "2026-08-14", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n- Docs & code: Name the exact API, error message, version or package.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-08-14. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Was ist eigentlich das Max-Planck-Institut und wie viel Forschungsgeld bekommen die vom Staat, falls das jemand weiß?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Was ist die Max-Planck-Gesellschaft und wie viel staatliche Forschungsförderung erhält sie?\", \"answer_shape\": \"profile\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Max-Planck-Gesellschaft Überblick Institute Aufgaben\", \"Max-Planck-Gesellschaft Haushalt Grundfinanzierung Bund Länder Millionen Euro\", \"Max-Planck-Gesellschaft Jahresbericht 2025 Zuwendungen\"], \"recency\": \"year\", \"complexity\": \"standard\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-891", "cat": "organisation", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["web"], "auto_lenses": false, "library": false, "web": true, "date": "2026-11-11", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-11-11. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "gibt es die firma hornbach noch richtig oder ist das nur ein baumarkt"}, {"role": "assistant", "content": "{\"standalone_question\": \"Gibt es die Firma Hornbach noch, oder ist Hornbach nur ein Baumarkt?\", \"answer_shape\": \"profile\", \"place\": \"\", \"wants_image\": true, \"image_query\": \"Hornbach logo\", \"needs_search\": true, \"search_queries\": [\"Hornbach Holding AG Unternehmen\", \"Hornbach Baumarkt Konzern Umsatz 2025\", \"Hornbach Holding Geschäftsbericht\"], \"recency\": \"year\", \"complexity\": \"simple\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-946", "cat": "look", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-08-23", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-08-23. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Ich mache gerade meinen Führerschein und muss die Verkehrszeichen lernen. Wie sieht das Zeichen für Vorfahrt achten aus?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Wie sieht das Verkehrszeichen für \\\"Vorfahrt achten\\\" in Deutschland aus?\", \"answer_shape\": \"image\", \"place\": \"\", \"wants_image\": true, \"image_query\": \"Vorfahrt achten traffic sign Germany\", \"needs_search\": true, \"search_queries\": [\"Verkehrszeichen 205 Vorfahrt achten\", \"Vorfahrt achten Zeichen Bild StVO\"], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [\"web\", \"reference\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-998", "cat": "explainer", "lang": "en", "settings": {"depth": "quick", "queries": 2, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-07-11", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 2 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-07-11. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Our smart thermostat keeps mentioning 'heat pump mode' and I have no clue what that is. How is it different from the furnace we had before?"}, {"role": "assistant", "content": "{\"standalone_question\": \"What is heat pump mode on a smart thermostat, and how does a heat pump differ from a furnace?\", \"answer_shape\": \"explainer\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"heat pump vs furnace how it works\", \"heat pump mode thermostat auxiliary emergency heat\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [\"web\", \"reference\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1028", "cat": "explainer", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-10-03", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-10-03. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "why do leaves change color in fall"}, {"role": "assistant", "content": "{\"standalone_question\": \"Why do leaves change color in fall?\", \"answer_shape\": \"explainer\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"autumn leaf color chlorophyll breakdown anthocyanin carotenoid mechanism\", \"why leaves change color autumn senescence photoperiod temperature\", \"anthocyanin biosynthesis autumn leaves function\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [\"reference\", \"scholar\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1032", "cat": "explainer", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["docs"], "auto_lenses": false, "library": false, "web": true, "date": "2027-10-17", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Docs & code: Name the exact API, error message, version or package.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-10-17. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "what is inflation and why does it happen"}, {"role": "assistant", "content": "{\"standalone_question\": \"What is inflation and why does it happen?\", \"answer_shape\": \"explainer\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"inflation definition causes demand-pull cost-push\", \"why does inflation happen economics explained\", \"inflation causes central bank monetary policy money supply\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1055", "cat": "explainer", "lang": "de", "settings": {"depth": "deep", "queries": 3, "sources": ["reference"], "auto_lenses": false, "library": false, "web": true, "date": "2027-01-30", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Reference: Name the subject as an encyclopaedia would title its article: the bare concept, without question words.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-01-30. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Meine Oma hat ein Sparbuch aus den 80ern und fragt, ob das noch was wert ist. Wie funktioniert eigentlich Zinseszins bei so alten Sparbüchern?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Ist ein Sparbuch aus den 1980er-Jahren heute noch etwas wert, und wie funktioniert der Zinseszins bei solchen alten Sparbüchern?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Sparbuch aus den 1980er Jahren Guthaben Verjährung Auszahlung\", \"Sparbuch Zinseszins Berechnung Zinsgutschrift alte Sparbücher\", \"Sparbuch Verjährungsfrist 30 Jahre Bank Ansprüche\"], \"recency\": \"year\", \"complexity\": \"standard\", \"lenses\": [], \"facets\": [\"callout\"], \"whole_library\": false}"}]}
{"id": "syn-1067", "cat": "explainer", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-10-21", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-10-21. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "wie werden eigentlich die punkte beim biathlon berechnet, bei den fehlschuessen"}, {"role": "assistant", "content": "{\"standalone_question\": \"Wie werden beim Biathlon die Strafen für Fehlschüsse berechnet?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Biathlon Strafrunde Strafminute Fehlschuss Regeln IBU\", \"Biathlon Strafen Einzel Sprint Verfolgung Massenstart Fehlschüsse\"], \"recency\": \"year\", \"complexity\": \"simple\", \"lenses\": [\"web\", \"reference\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1087", "cat": "explainer", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["reference"], "auto_lenses": false, "library": false, "web": true, "date": "2026-10-09", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Reference: Name the subject as an encyclopaedia would title its article: the bare concept, without question words.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-10-09. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "warum wird ein kondensator im netzteil so heiß"}, {"role": "assistant", "content": "{\"standalone_question\": \"Warum wird ein Kondensator im Netzteil so heiß?\", \"answer_shape\": \"explainer\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Elektrolytkondensator Erwärmung Ripplestrom\", \"Elektrolytkondensator Netzteil ESR Verlustleistung\", \"Netzteil Kondensator Überhitzung Ursachen Lebensdauer\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1089", "cat": "explainer", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["web", "scholar"], "auto_lenses": false, "library": false, "web": true, "date": "2026-12-26", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n- Science: Write these in English whatever language the question is in: Crossref, arXiv, OpenAlex and PubMed index English titles and abstracts, and a German query returns whatever happened to share a word with it. Use the field's own terminology and name the population, intervention or mechanism. These are bibliographic databases, not a search box.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-12-26. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "wieso brauch ich bei pvc fenstern eine dampfsperre und was passiert wenn ich die weglasse"}, {"role": "assistant", "content": "{\"standalone_question\": \"Warum braucht man bei PVC-Fenstern eine Dampfsperre und was passiert, wenn man sie weglässt?\", \"answer_shape\": \"explainer\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Dampfsperre Fenstereinbau Anschluss PVC-Fenster\", \"Dampfsperre weglassen Fenster Schimmel Kondensat\", \"Fensteranschluss RAL-Montage Innenabdichtung Dampfbremse\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1114", "cat": "steps", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-07-23", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-07-23. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "how do i file a small claims form in ohio"}, {"role": "assistant", "content": "{\"standalone_question\": \"How do I file a small claims form in Ohio?\", \"answer_shape\": \"steps\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Ohio small claims court how to file complaint\", \"Ohio small claims filing fees forms county municipal court\"], \"recency\": \"year\", \"complexity\": \"standard\", \"lenses\": [\"web\", \"reference\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1130", "cat": "steps", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["web", "scholar"], "auto_lenses": false, "library": false, "web": true, "date": "2026-10-15", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n- Science: Write these in English whatever language the question is in: Crossref, arXiv, OpenAlex and PubMed index English titles and abstracts, and a German query returns whatever happened to share a word with it. Use the field's own terminology and name the population, intervention or mechanism. These are bibliographic databases, not a search box.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-10-15. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "clean dryer vent safely step by step"}, {"role": "assistant", "content": "{\"standalone_question\": \"How do I clean a clothes dryer vent safely, step by step?\", \"answer_shape\": \"steps\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"clean dryer vent safely step by step\", \"dryer vent cleaning instructions lint removal\", \"dryer vent cleaning fire safety tips\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1138", "cat": "steps", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["scholar"], "auto_lenses": false, "library": false, "web": true, "date": "2027-04-30", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Science: Write these in English whatever language the question is in: Crossref, arXiv, OpenAlex and PubMed index English titles and abstracts, and a German query returns whatever happened to share a word with it. Use the field's own terminology and name the population, intervention or mechanism. These are bibliographic databases, not a search box.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-04-30. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Can you explain how to set up a shared family calendar on my phone and my partner's phone so we both see the kids' school events?"}, {"role": "assistant", "content": "{\"standalone_question\": \"How do I set up a shared family calendar on two phones so both partners see the children's school events?\", \"answer_shape\": \"steps\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"share Google Calendar with another person Android iPhone\", \"share iCloud calendar family sharing iPhone\", \"shared family calendar app school events two phones setup\"], \"recency\": \"year\", \"complexity\": \"standard\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1145", "cat": "steps", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["web", "scholar"], "auto_lenses": false, "library": false, "web": true, "date": "2026-11-25", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n- Science: Write these in English whatever language the question is in: Crossref, arXiv, OpenAlex and PubMed index English titles and abstracts, and a German query returns whatever happened to share a word with it. Use the field's own terminology and name the population, intervention or mechanism. These are bibliographic databases, not a search box.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-11-25. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "What steps do I need to take to renew my driver's license online before it expires next month?"}, {"role": "assistant", "content": "{\"standalone_question\": \"What steps do I need to take to renew my driver's license online before it expires next month?\", \"answer_shape\": \"steps\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"driver license renewal online steps\", \"driver's license renew online requirements\", \"renew driver's license online before expiry\"], \"recency\": \"year\", \"complexity\": \"standard\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1215", "cat": "comparison", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-12-31", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-12-31. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Should I use wood glue or epoxy to repair a cracked chair leg that gets a lot of weight on it?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Should I use wood glue or epoxy to repair a cracked chair leg that bears a lot of weight?\", \"answer_shape\": \"comparison\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"wood glue vs epoxy chair leg repair strength\", \"PVA wood glue versus epoxy structural furniture repair load\", \"repairing cracked chair leg glue choice\"], \"recency\": \"\", \"complexity\": \"research\", \"lenses\": [\"web\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1243", "cat": "comparison", "lang": "en", "settings": {"depth": "quick", "queries": 2, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-04-11", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 2 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-04-11. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Should I use a 6 oz or 8 oz graphite shaft for a tennis racket if I have tennis elbow?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Should I use a 6 oz or 8 oz graphite shaft for a tennis racket if I have tennis elbow?\", \"answer_shape\": \"comparison\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"tennis elbow lateral epicondylitis racket weight vibration\", \"lateral epicondylitis racket mass stiffness string tension study\"], \"recency\": \"\", \"complexity\": \"research\", \"lenses\": [\"web\", \"scholar\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1244", "cat": "comparison", "lang": "en", "settings": {"depth": "deep", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-10-24", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-10-24. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Should I get a power meter pedal or a crank-based power meter for my first training block?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Should I get a power meter pedal or a crank-based power meter for my first training block?\", \"answer_shape\": \"comparison\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"power meter pedals vs crank power meter comparison\", \"power meter pedal accuracy single sided dual sided cycling\", \"best power meter for beginner cyclist training\"], \"recency\": \"year\", \"complexity\": \"research\", \"lenses\": [\"web\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1273", "cat": "comparison", "lang": "de", "settings": {"depth": "quick", "queries": 2, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-02-26", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 2 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-02-26. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Soll ich für die Gartenbewässerung Regenwasser aus der Tonne oder Brunnenwasser nutzen, Stichwort Kalk und Keime?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Soll ich für die Gartenbewässerung Regenwasser aus der Regentonne oder Brunnenwasser nutzen, mit Blick auf Kalk und Keime?\", \"answer_shape\": \"comparison\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"rainwater harvesting microbial contamination irrigation well water comparison\", \"Regenwasser Regentonne Gartenbewässerung Brunnenwasser Kalk Keime Hygiene\"], \"recency\": \"\", \"complexity\": \"research\", \"lenses\": [\"web\", \"scholar\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1313", "cat": "comparison", "lang": "de", "settings": {"depth": "quick", "queries": 2, "sources": ["web", "scholar"], "auto_lenses": false, "library": false, "web": true, "date": "2026-11-29", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 2 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n- Science: Write these in English whatever language the question is in: Crossref, arXiv, OpenAlex and PubMed index English titles and abstracts, and a German query returns whatever happened to share a word with it. Use the field's own terminology and name the population, intervention or mechanism. These are bibliographic databases, not a search box.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-11-29. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Für Cyberpunk 2077 Phantom Liberty, lohnt sich der Kauf der Deluxe-Edition oder reicht die Standard-Version?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Lohnt sich die Deluxe-Edition von Cyberpunk 2077 mit Phantom Liberty gegenüber der Standard-Version?\", \"answer_shape\": \"comparison\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Cyberpunk 2077 Deluxe Edition Inhalt Unterschied Standard\", \"Cyberpunk 2077 Phantom Liberty Preis aktuell\"], \"recency\": \"year\", \"complexity\": \"research\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1337", "cat": "table", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-01-14", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-01-14. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "stripe vs square vs paypal for a small shop, processing fees"}, {"role": "assistant", "content": "{\"standalone_question\": \"Stripe vs Square vs PayPal processing fees for a small online shop\", \"answer_shape\": \"table\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Stripe vs Square vs PayPal processing fees 2026\", \"Stripe Square PayPal transaction fee rates small business\", \"Square online checkout fee PayPal business rates\"], \"recency\": \"year\", \"complexity\": \"research\", \"lenses\": [\"web\", \"data\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1341", "cat": "table", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["reference"], "auto_lenses": false, "library": false, "web": true, "date": "2027-08-19", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Reference: Name the subject as an encyclopaedia would title its article: the bare concept, without question words.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-08-19. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "vergleich mal lissabon porto und madeira für nen 10 tage urlaub im herbst, was ist günstiger und wo ist das wetter besser"}, {"role": "assistant", "content": "{\"standalone_question\": \"Vergleich Lissabon, Porto und Madeira für einen 10-tägigen Herbsturlaub: Welcher Ort ist günstiger und wo ist das Wetter im Herbst besser?\", \"answer_shape\": \"table\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Lissabon Porto Madeira Preise Unterkunft Herbst\", \"Lissabon Porto Madeira Klima Temperatur Niederschlag September Oktober November\", \"Madeira Flug Lissabon Porto Kosten Urlaub 10 Tage\"], \"recency\": \"year\", \"complexity\": \"research\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1356", "cat": "table", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["reference"], "auto_lenses": false, "library": false, "web": true, "date": "2027-12-07", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Reference: Name the subject as an encyclopaedia would title its article: the bare concept, without question words.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-12-07. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "netflix disney plus amazon prime video, was lohnt sich wenn ich hauptsächlich serien schaue"}, {"role": "assistant", "content": "{\"standalone_question\": \"Welches Streaming-Abo lohnt sich am meisten, wenn ich hauptsächlich Serien schaue: Netflix, Disney+ oder Amazon Prime Video?\", \"answer_shape\": \"table\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Netflix Disney+ Prime Video Preise Deutschland 2027\", \"Netflix Disney+ Prime Video Serien Vergleich Test\", \"Streaming Abo Vergleich Serienangebot Deutschland\"], \"recency\": \"year\", \"complexity\": \"research\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1378", "cat": "evidence", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-12-31", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-12-31. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "does music during surgery actually lower anxiety and pain meds needed"}, {"role": "assistant", "content": "{\"standalone_question\": \"Does listening to music during surgery actually lower anxiety and the amount of pain medication needed?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"music intervention intraoperative anxiety meta-analysis\", \"music intraoperative analgesic opioid consumption randomized trials\"], \"recency\": \"\", \"complexity\": \"research\", \"lenses\": [\"scholar\", \"web\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1381", "cat": "evidence", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["web", "data"], "auto_lenses": false, "library": false, "web": true, "date": "2027-11-02", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n- Data: Name the quantity the way a calculator would take it (`AAPL stock price`, `100 USD in EUR`, `population of Berlin`), not as a sentence.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-11-02. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "do blue light glasses help you sleep better or is it placebo"}, {"role": "assistant", "content": "{\"standalone_question\": \"Do blue light blocking glasses help you sleep better, or is the effect just placebo?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"blue light blocking glasses sleep randomized trial\", \"blue light glasses melatonin systematic review\", \"blue light glasses placebo sleep study\"], \"recency\": \"\", \"complexity\": \"research\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1400", "cat": "evidence", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-01-04", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-01-04. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Hi, my teenager spends most of his free time on Minecraft and Roblox, is there research linking that to anxiety or depression?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Is there research linking playing Minecraft and Roblox to anxiety or depression in teenagers?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"video game play adolescents anxiety depression longitudinal\", \"problematic gaming adolescent depressive symptoms meta-analysis\", \"Minecraft Roblox adolescent mental health\"], \"recency\": \"\", \"complexity\": \"research\", \"lenses\": [\"scholar\", \"web\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1432", "cat": "evidence", "lang": "en", "settings": {"depth": "deep", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-06-29", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-06-29. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "I use a standing desk I built from an old table and an electric lift, and my shoulders still get tight by afternoon. Do studies show standing desks reduce back or neck pain, or is it mostly about switching positions?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Do studies show that standing desks reduce back or neck pain, or is the benefit mostly from switching between sitting and standing positions?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"sit-stand desk low back neck pain randomized trial\", \"standing desk musculoskeletal pain systematic review\", \"alternating sitting standing office workers pain intervention\"], \"recency\": \"\", \"complexity\": \"research\", \"lenses\": [\"scholar\", \"web\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1435", "cat": "evidence", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-04-26", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-04-26. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Started taking vitamin D because I work indoors all day and my mood's been low through winter. Does the research actually support vitamin D helping with mood or is it mostly a placebo effect?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Does the research support vitamin D supplementation improving mood, particularly in people with low mood in winter, or is the effect mostly placebo?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"vitamin D supplementation depressive symptoms randomized controlled trial meta-analysis\", \"vitamin D seasonal affective disorder winter mood trial\", \"vitamin D mood healthy adults placebo-controlled systematic review\"], \"recency\": \"year\", \"complexity\": \"research\", \"lenses\": [\"web\", \"scholar\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1439", "cat": "evidence", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["web"], "auto_lenses": false, "library": false, "web": true, "date": "2026-09-28", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-09-28. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "My roommate swears cold showers boost mood and immunity. Is there any solid research on that or is it mostly anecdotal?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Is there solid research that cold showers boost mood and immunity, or is the evidence mostly anecdotal?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"cold water immersion mood depression randomized trial\", \"cold shower immune function study\", \"cold exposure immunity systematic review\"], \"recency\": \"\", \"complexity\": \"research\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1466", "cat": "evidence", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["web"], "auto_lenses": false, "library": false, "web": true, "date": "2027-08-07", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-08-07. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "macht Krafttraining ältere Leute weniger sturzgefährdet"}, {"role": "assistant", "content": "{\"standalone_question\": \"Macht Krafttraining ältere Menschen weniger sturzgefährdet?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Krafttraining Sturzprävention ältere Menschen Studie\", \"Krafttraining Sturzrisiko Senioren Metaanalyse\", \"Kraftraining Sturzprophylaxe Leitlinie\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1468", "cat": "evidence", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["scholar"], "auto_lenses": false, "library": false, "web": true, "date": "2027-01-07", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Science: Write these in English whatever language the question is in: Crossref, arXiv, OpenAlex and PubMed index English titles and abstracts, and a German query returns whatever happened to share a word with it. Use the field's own terminology and name the population, intervention or mechanism. These are bibliographic databases, not a search box.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-01-07. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "was passiert mit dem körper wenn man 3 tage nichts isst"}, {"role": "assistant", "content": "{\"standalone_question\": \"Was passiert mit dem menschlichen Körper, wenn man 3 Tage lang nichts isst?\", \"answer_shape\": \"explainer\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"72 Stunden Fasten Stoffwechsel Körper Auswirkungen\", \"Hungerstoffwechsel Glykogen Ketose nach 72 Stunden\", \"prolonged fasting 72 hours physiological effects review\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1478", "cat": "evidence", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-02-06", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-02-06. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Ist Ibuprofen nach dem Krafttraining schädlich für den Muskelaufbau, wie ich es irgendwo gelesen habe? Was zeigen die Studien?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Ist Ibuprofen nach dem Krafttraining schädlich für den Muskelaufbau, und was zeigen die Studien dazu?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"ibuprofen NSAID resistance training muscle hypertrophy\", \"NSAID muscle protein synthesis after resistance exercise randomized trial\", \"NSAIDs strength gains muscle growth meta-analysis\"], \"recency\": \"\", \"complexity\": \"research\", \"lenses\": [\"web\", \"scholar\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1595", "cat": "docs", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-12-06", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-12-06. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "github actions cache key restore-keys fallback"}, {"role": "assistant", "content": "{\"standalone_question\": \"How do the restore-keys fallback options work in GitHub Actions cache keys?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"github actions cache restore-keys fallback\", \"actions/cache restore-keys prefix match order\"], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [\"docs\", \"web\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1614", "cat": "docs", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["reference"], "auto_lenses": false, "library": false, "web": true, "date": "2026-02-06", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Reference: Name the subject as an encyclopaedia would title its article: the bare concept, without question words.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-02-06. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "How do I configure the Redis maxmemory-policy setting so that cached drug interaction lookups get evicted gracefully under memory pressure?"}, {"role": "assistant", "content": "{\"standalone_question\": \"How do I configure the Redis maxmemory-policy setting so that cached drug interaction lookups get evicted gracefully under memory pressure?\", \"answer_shape\": \"steps\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Redis maxmemory-policy eviction policies\", \"Redis maxmemory configuration redis.conf CONFIG SET\", \"Redis allkeys-lru volatile-lru TTL eviction cache\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1660", "cat": "docs", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-07-19", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-07-19. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "wie aktiviere ich in nginx gzip compression für json responses"}, {"role": "assistant", "content": "{\"standalone_question\": \"Wie aktiviere ich gzip-Kompression für JSON-Antworten in nginx?\", \"answer_shape\": \"steps\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"nginx gzip module gzip_types application/json\", \"nginx gzip on gzip_min_length gzip_comp_level configuration\"], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [\"docs\", \"web\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1664", "cat": "docs", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["web", "docs"], "auto_lenses": false, "library": false, "web": true, "date": "2027-01-26", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n- Docs & code: Name the exact API, error message, version or package.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-01-26. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "was macht der parameter --no-cache bei docker build genau"}, {"role": "assistant", "content": "{\"standalone_question\": \"Was macht der Parameter --no-cache bei docker build genau?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"docker build --no-cache flag\", \"docker build no-cache option documentation\"], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1678", "cat": "news", "lang": "en", "settings": {"depth": "quick", "queries": 2, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-11-24", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 2 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-11-24. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "what happened with that major airline strike, is it resolved yet"}, {"role": "assistant", "content": "{\"standalone_question\": \"What happened with the major airline strike, and has it been resolved yet?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"major airline strike resolved\", \"airline strike latest news\"], \"recency\": \"month\", \"complexity\": \"standard\", \"lenses\": [\"news\", \"web\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1696", "cat": "news", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-05-19", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-05-19. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "any fresh news on the housing market cooling off this month"}, {"role": "assistant", "content": "{\"standalone_question\": \"Any fresh news on the housing market cooling off in May 2026?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"housing market cooling May 2026\", \"home sales prices slowdown May 2026 news\"], \"recency\": \"month\", \"complexity\": \"standard\", \"lenses\": [\"news\", \"web\"], \"facets\": [\"timeline\"], \"whole_library\": false}"}]}
{"id": "syn-1699", "cat": "news", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["web", "data"], "auto_lenses": false, "library": false, "web": true, "date": "2026-11-16", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n- Data: Name the quantity the way a calculator would take it (`AAPL stock price`, `100 USD in EUR`, `population of Berlin`), not as a sentence.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-11-16. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "I'm a high school history teacher preparing a lesson on recent education policy, so can you tell me what the latest news is on the US Department of Education's federal student loan forgiveness rules this week?"}, {"role": "assistant", "content": "{\"standalone_question\": \"What is the latest news this week on US Department of Education federal student loan forgiveness rules?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Department of Education student loan forgiveness news\", \"federal student loan forgiveness rule changes 2026\", \"student loan forgiveness latest week\"], \"recency\": \"week\", \"complexity\": \"standard\", \"lenses\": [], \"facets\": [\"timeline\"], \"whole_library\": false}"}]}
{"id": "syn-1716", "cat": "news", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-09-16", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-09-16. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Trying to decide whether to switch from public to private school for my kid. What's the latest on school voucher programs passed by state legislatures this year?"}, {"role": "assistant", "content": "{\"standalone_question\": \"What school voucher programs have state legislatures passed in 2026?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"school voucher program passed state legislature 2026\", \"education savings account bill signed into law 2026\", \"universal school choice law states 2026 private school tuition\"], \"recency\": \"year\", \"complexity\": \"standard\", \"lenses\": [\"news\", \"web\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1724", "cat": "news", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-09-23", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-09-23. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "gibts neue infos zur grippewelle in deutschland diese woche? wirds schlimmer?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Gibt es neue Informationen zur Grippewelle in Deutschland diese Woche, und wird sie schlimmer?\", \"answer_shape\": \"series\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Grippewelle Deutschland aktuell RKI Influenza Wochenbericht\", \"Influenza Aktivität Deutschland September 2027\", \"Grippe Infektionen Deutschland Entwicklung neue Daten\"], \"recency\": \"week\", \"complexity\": \"standard\", \"lenses\": [\"news\", \"data\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1737", "cat": "news", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-09-09", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-09-09. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "gibts aktuell probleme mit der tetanus impfung oder lieferengpässe"}, {"role": "assistant", "content": "{\"standalone_question\": \"Gibt es aktuell Probleme oder Lieferengpässe bei der Tetanus-Impfung in Deutschland?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Tetanus Impfstoff Lieferengpass 2026\", \"Td-Impfstoff Versorgung Deutschland BfArM\", \"Tetanus Impfung Probleme Rückruf Lieferprobleme\"], \"recency\": \"year\", \"complexity\": \"standard\", \"lenses\": [\"web\", \"news\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1743", "cat": "news", "lang": "de", "settings": {"depth": "quick", "queries": 2, "sources": ["reference"], "auto_lenses": false, "library": false, "web": true, "date": "2027-04-22", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 2 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Reference: Name the subject as an encyclopaedia would title its article: the bare concept, without question words.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-04-22. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "welche news zu dem zugunglück letzte woche, wie ist der stand bei den ermittlungen"}, {"role": "assistant", "content": "{\"standalone_question\": \"Welche aktuellen Nachrichten gibt es zu dem Zugunglück der letzten Woche (April 2027), und wie ist der Stand der Ermittlungen?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Zugunglück Ermittlungen Stand April 2027\", \"Zugunglück letzte Woche Nachrichten Ursache\"], \"recency\": \"week\", \"complexity\": \"standard\", \"lenses\": [], \"facets\": [\"timeline\"], \"whole_library\": false}"}]}
{"id": "syn-1773", "cat": "news", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-04-28", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-04-28. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Ich bin Erzieherin in einer Kita in Leipzig und wir suchen dringend Personal. Was gibt es Neues zur Kita-Finanzierung oder zum Fachkräfteprogramm des Bundes?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Was gibt es Neues zur Kita-Finanzierung und zum Fachkräfteprogramm des Bundes für Kitas in Leipzig?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Kita-Finanzierung Bund Länder 2026\", \"Fachkräfteprogramm Kita Bund 2026\", \"Leipzig Kita Fachkräfte Finanzierung 2026\"], \"recency\": \"year\", \"complexity\": \"standard\", \"lenses\": [\"news\", \"web\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1788", "cat": "history", "lang": "en", "settings": {"depth": "deep", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-03-08", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-03-08. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "how did the first email get sent and who sent it"}, {"role": "assistant", "content": "{\"standalone_question\": \"How was the first email sent, and who sent it?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"first email sent Ray Tomlinson 1971 ARPANET\", \"Tomlinson first networked email history @ symbol\"], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [\"web\", \"reference\"], \"facets\": [\"timeline\"], \"whole_library\": false}"}]}
{"id": "syn-1805", "cat": "history", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-11-13", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-11-13. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Mein Opa hatte früher einen Bausparvertrag bei der Bausparkasse Schwäbisch Hall. Wie hat sich das Bausparen in Deutschland seit den 70ern entwickelt?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Wie hat sich das Bausparen in Deutschland seit den 1970er-Jahren entwickelt?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Bausparen Deutschland Geschichte seit 1970\", \"Bausparkassen Entwicklung Wohnungsbauprämie Zinsen Reformen\", \"Bausparverträge Entwicklung Neugeschäft Bestand Statistik\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [\"web\", \"reference\"], \"facets\": [\"timeline\"], \"whole_library\": false}"}]}
{"id": "syn-1818", "cat": "history", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["reference"], "auto_lenses": false, "library": false, "web": true, "date": "2027-08-01", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Reference: Name the subject as an encyclopaedia would title its article: the bare concept, without question words.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-08-01. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Ich habe eine Kreditkarte von meiner Bank bekommen und verstehe den Jahresbeitrag nicht. Wie entstand das Modell der Kreditkarte in Deutschland?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Wie entstand das Modell der Kreditkarte mit Jahresbeitrag in Deutschland?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Kreditkarte\", \"Geschichte der Kreditkarte in Deutschland\", \"Entstehung Kreditkarte Jahresgebühr Modell\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [], \"facets\": [\"timeline\"], \"whole_library\": false}"}]}
{"id": "syn-1824", "cat": "history", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-06-10", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-06-10. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Mein Papa hat früher immer die Telekom-Aktien gelobt. Wie kam es zur Privatisierung der Telekom und was ist seit dem Börsengang passiert?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Wie kam es zur Privatisierung der Deutschen Telekom und was ist seit dem Börsengang der Telekom-Aktie passiert?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Privatisierung Deutsche Telekom Börsengang 1996 Geschichte\", \"Deutsche Telekom Aktie Entwicklung seit Börsengang Ereignisse\", \"Deutsche Telekom Bund Anteil Verkauf 2024 2025 2026\"], \"recency\": \"year\", \"complexity\": \"standard\", \"lenses\": [\"web\", \"reference\"], \"facets\": [\"timeline\"], \"whole_library\": false}"}]}
{"id": "syn-1827", "cat": "decision", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["web"], "auto_lenses": false, "library": false, "web": true, "date": "2026-06-04", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-06-04. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "should i register as self employed or stay on the freelance tax form"}, {"role": "assistant", "content": "{\"standalone_question\": \"Should I register as self-employed or stay on the freelance tax form?\", \"answer_shape\": \"comparison\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"register as self-employed vs freelance tax form differences\", \"self-employed registration freelancer tax obligations pros and cons\", \"freelancer tax registration deadline penalties self-employed\"], \"recency\": \"year\", \"complexity\": \"standard\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1857", "cat": "decision", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-04-21", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-04-21. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "pros and cons of moving to a farm to be closer to wildlife"}, {"role": "assistant", "content": "{\"standalone_question\": \"What are the pros and cons of moving to a farm to be closer to wildlife?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"moving to rural farm living pros and cons wildlife\", \"living on a farm closer to wildlife drawbacks costs\", \"rural homestead wildlife encounters benefits downsides\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [\"web\"], \"facets\": [\"proscons\"], \"whole_library\": false}"}]}
{"id": "syn-1861", "cat": "decision", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["web", "news"], "auto_lenses": false, "library": false, "web": true, "date": "2027-11-09", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n- News: Name the event, the organisation and the period being asked about.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-11-09. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "pros and cons of volunteering at a wildlife rehab center on weekends"}, {"role": "assistant", "content": "{\"standalone_question\": \"What are the pros and cons of volunteering at a wildlife rehabilitation center on weekends?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"wildlife rehabilitation center volunteer pros and cons\", \"wildlife rehab volunteer weekend time commitment training requirements\", \"wildlife rehabilitation volunteering drawbacks burnout experience\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [], \"facets\": [\"proscons\"], \"whole_library\": false}"}]}
{"id": "syn-1884", "cat": "decision", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["web"], "auto_lenses": false, "library": false, "web": true, "date": "2027-12-14", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-12-14. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Pro Contra Teilzeit auf 75% wegen Pflege meiner Mutter, Rentenpunkte und Karriere im Hinterkopf?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Pro und Contra: Teilzeit auf 75 % wegen der Pflege meiner Mutter, mit Blick auf Rentenpunkte und Karriere\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Pflege Angehöriger Teilzeit Rentenpunkte Pflegepflichtzeiten\", \"Familienpflegezeit Pflegeunterstützungsgeld Teilzeit Anspruch\", \"Teilzeit 75 Prozent Karriere Nachteile Pflege Angehöriger\"], \"recency\": \"year\", \"complexity\": \"research\", \"lenses\": [], \"facets\": [\"proscons\"], \"whole_library\": false}"}]}
{"id": "syn-1886", "cat": "decision", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-01-16", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-01-16. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Lohnt sich ein Abo bei Netflix plus Disney plus, oder reicht eines davon für meine Serien?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Lohnt sich ein Abo bei Netflix plus Disney+, oder reicht eines davon für meine Serien?\", \"answer_shape\": \"comparison\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Netflix Disney+ Preise Deutschland 2027 Werbung Standard Premium\", \"Disney+ Netflix Serien Vergleich Inhalte Abo kündigen\"], \"recency\": \"year\", \"complexity\": \"standard\", \"lenses\": [\"web\", \"data\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1893", "cat": "decision", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["docs"], "auto_lenses": false, "library": false, "web": true, "date": "2026-01-25", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Docs & code: Name the exact API, error message, version or package.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-01-25. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Sollte ich die Lasikbehandlung machen bei -3,5 Dioptrien und dünner Hornhaut, oder sind Kontaktlinsen die bessere Wahl?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Sollte ich bei -3,5 Dioptrien und dünner Hornhaut eine LASIK-Behandlung machen, oder sind Kontaktlinsen die bessere Wahl?\", \"answer_shape\": \"comparison\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"LASIK dünne Hornhaut Kontraindikation Hornhautdicke Kriterien\", \"LASIK versus Kontaktlinsen Kurzsichtigkeit Vor- und Nachteile\", \"ICL Linsenimplantat Alternative LASIK dünne Hornhaut\"], \"recency\": \"\", \"complexity\": \"research\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1915", "cat": "decision", "lang": "de", "settings": {"depth": "deep", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-10-12", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-10-12. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Vorteile und Nachteile Start-up vs Konzern"}, {"role": "assistant", "content": "{\"standalone_question\": \"Welche Vorteile und Nachteile hat ein Start-up gegenüber einem Konzern?\", \"answer_shape\": \"comparison\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Vorteile Nachteile Start-up vs Konzern Arbeiten\", \"Start-up oder Konzern Karriere Unterschiede Gehalt Work-Life-Balance\", \"Arbeiten im Start-up Nachteile Risiko Stock Options\"], \"recency\": \"\", \"complexity\": \"research\", \"lenses\": [\"web\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-1925", "cat": "decision", "lang": "de", "settings": {"depth": "quick", "queries": 2, "sources": ["scholar"], "auto_lenses": false, "library": false, "web": true, "date": "2027-07-02", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 2 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Science: Write these in English whatever language the question is in: Crossref, arXiv, OpenAlex and PubMed index English titles and abstracts, and a German query returns whatever happened to share a word with it. Use the field's own terminology and name the population, intervention or mechanism. These are bibliographic databases, not a search box.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-07-02. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "lohnt sich der Kauf einer Wärmepumpe 2024"}, {"role": "assistant", "content": "{\"standalone_question\": \"Lohnt sich der Kauf einer Wärmepumpe im Jahr 2024?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Wärmepumpe Wirtschaftlichkeit 2024 Anschaffungskosten Heizkosten Vergleich Gasheizung\", \"Wärmepumpe BEG Förderung 2024 Strompreis Betriebskosten\"], \"recency\": \"year\", \"complexity\": \"standard\", \"lenses\": [], \"facets\": [\"proscons\"], \"whole_library\": false}"}]}
{"id": "syn-1941", "cat": "list", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-05-21", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-05-21. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "side effects of creatine monohydrate supplementation on kidney function markers in healthy adults"}, {"role": "assistant", "content": "{\"standalone_question\": \"What are the side effects of creatine monohydrate supplementation on kidney function markers in healthy adults?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"creatine monohydrate supplementation kidney function healthy adults\", \"creatine supplementation serum creatinine eGFR randomized trial\", \"creatine kidney safety systematic review\"], \"recency\": \"year\", \"complexity\": \"research\", \"lenses\": [\"scholar\", \"web\"], \"facets\": [\"proscons\"], \"whole_library\": false}"}]}
{"id": "syn-1966", "cat": "list", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-12-14", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-12-14. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Meine Freundin will ihren alten Laptop verkaufen und wissen, welche Zutaten im Akku-Chemie-Mix stecken, weil sie Angst vor Brandgefahr hat. Was steht da drin?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Welche Bestandteile enthält der Lithium-Ionen-Akku eines Laptops (Kathode, Anode, Elektrolyt, Separator), und welche davon sind brennbar?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Lithium-Ionen-Akku Zusammensetzung Kathode Anode Elektrolyt Separator\", \"Lithium-Ionen-Akku Brandgefahr Elektrolyt LiPF6 brennbar\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [\"reference\", \"web\"], \"facets\": [\"list\"], \"whole_library\": false}"}]}
{"id": "syn-1975", "cat": "list", "lang": "de", "settings": {"depth": "quick", "queries": 2, "sources": ["web", "scholar"], "auto_lenses": false, "library": false, "web": true, "date": "2027-09-20", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 2 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n- Science: Write these in English whatever language the question is in: Crossref, arXiv, OpenAlex and PubMed index English titles and abstracts, and a German query returns whatever happened to share a word with it. Use the field's own terminology and name the population, intervention or mechanism. These are bibliographic databases, not a search box.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-09-20. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Ich bin Entwickler und unser Docker-Build dauert ewig. Welche Symptome deuten auf einen Cache-Fehler im Layer-System hin?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Welche Symptome deuten bei einem Docker-Build auf einen Cache-Fehler im Layer-System hin?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"docker build cache miss every build symptoms\", \"docker layer cache not used slow build troubleshooting\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [], \"facets\": [\"list\"], \"whole_library\": false}"}]}
{"id": "syn-2042", "cat": "multipart", "lang": "en", "settings": {"depth": "quick", "queries": 2, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-08-27", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 2 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-08-27. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "compare the ps5 pro and xbox series x price right now and which has better 4k frame rates in recent reviews"}, {"role": "assistant", "content": "{\"standalone_question\": \"What is the current price of the PS5 Pro versus the Xbox Series X, and which console has better 4K frame rates in recent reviews?\", \"answer_shape\": \"comparison\", \"place\": \"\", \"wants_image\": true, \"image_query\": \"PlayStation 5 Pro\", \"needs_search\": true, \"search_queries\": [\"PS5 Pro vs Xbox Series X price 2026\", \"PS5 Pro vs Xbox Series X 4K frame rate review\"], \"recency\": \"year\", \"complexity\": \"research\", \"lenses\": [\"web\", \"data\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2066", "cat": "multipart", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-09-26", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-09-26. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "was ist der unterschied zwischen einer probezeit und einer befristung bei arbeitsverträgen in deutschland"}, {"role": "assistant", "content": "{\"standalone_question\": \"Was ist der Unterschied zwischen einer Probezeit und einer Befristung bei Arbeitsverträgen in Deutschland?\", \"answer_shape\": \"comparison\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Probezeit Befristung Arbeitsvertrag Unterschied Kündigungsfrist\", \"Probezeit Arbeitsrecht Deutschland maximal 6 Monate TzBfG\", \"befristeter Arbeitsvertrag Sachgrund Voraussetzungen TzBfG\"], \"recency\": \"year\", \"complexity\": \"standard\", \"lenses\": [\"web\", \"reference\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2083", "cat": "rules", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-04-02", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-04-02. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "I finished my bachelor's in Ireland last June and my Stamp 1G is expiring soon. Can I apply to extend it for a job search, and what's the deadline to submit the application before it runs out?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Can I extend my Irish Stamp 1G permission to search for work after completing a bachelor's degree in Ireland, and what is the deadline to apply before it expires?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Stamp 1G extension job search Ireland\", \"Stamp 1G renewal deadline before expiry INIS\", \"Irish Immigration Service Stamp 1G graduate eligibility requirements\"], \"recency\": \"year\", \"complexity\": \"standard\", \"lenses\": [\"web\", \"reference\"], \"facets\": [\"callout\"], \"whole_library\": false}"}]}
{"id": "syn-2104", "cat": "rules", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["docs"], "auto_lenses": false, "library": false, "web": true, "date": "2026-12-08", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Docs & code: Name the exact API, error message, version or package.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-12-08. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "What is the deadline to file a notice of intent to relocate with my child's school district in California if we move out of the attendance zone mid-semester?"}, {"role": "assistant", "content": "{\"standalone_question\": \"In California, what is the deadline for filing a notice of intent to relocate with a child's school district when the family moves out of the attendance zone mid-semester?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"California school district notice of intent to relocate deadline mid-semester\", \"California Education Code 48204 move out of attendance area mid-year\", \"California school enrollment after moving out of district notice requirements\"], \"recency\": \"year\", \"complexity\": \"standard\", \"lenses\": [], \"facets\": [\"callout\"], \"whole_library\": false}"}]}
{"id": "syn-2124", "cat": "rules", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-03-21", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-03-21. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "What are the deadlines for a Brazilian employee to file a labor claim against an employer for unpaid overtime, and does the three-year prescription period start from the termination date?"}, {"role": "assistant", "content": "{\"standalone_question\": \"What are the deadlines for a Brazilian employee to file a labor claim against an employer for unpaid overtime, and does the three-year prescription period start from the termination date?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"prescrição trabalhista horas extras CLT art. 7 XXIX\", \"prazo prescricional cinco anos dois anos após extinção contrato trabalho\", \"prescrição trabalhista termo inicial rescisão contrato\"], \"recency\": \"year\", \"complexity\": \"standard\", \"lenses\": [\"web\", \"reference\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2136", "cat": "rules", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-12-03", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-12-03. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Mein Arbeitgeber will mir kündigen weil ich angeblich zu oft krank war, dabei hatte ich nur einen Bandscheibenvorfall. Wie lange habe ich Zeit, eine Kündigungsschutzklage einzureichen?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Wie lange habe ich Zeit, eine Kündigungsschutzklage einzureichen, wenn mein Arbeitgeber mir wegen angeblich häufiger Krankheit (nach einem Bandscheibenvorfall) kündigt?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Kündigungsschutzklage Frist 3 Wochen § 4 KSchG\", \"Kündigungsschutzklage Frist Zugang Kündigung verpasst nachträglich zulassen\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [\"web\"], \"facets\": [\"callout\"], \"whole_library\": false}"}]}
{"id": "syn-2177", "cat": "rules", "lang": "de", "settings": {"depth": "quick", "queries": 2, "sources": ["web", "data"], "auto_lenses": false, "library": false, "web": true, "date": "2026-05-25", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 2 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n- Data: Name the quantity the way a calculator would take it (`AAPL stock price`, `100 USD in EUR`, `population of Berlin`), not as a sentence.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-05-25. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Ab welchem Alter darf man in der Schweiz alleine Auto fahren und gilt der deutsche Führerschein dort noch"}, {"role": "assistant", "content": "{\"standalone_question\": \"Ab welchem Alter darf man in der Schweiz alleine Auto fahren, und gilt der deutsche Führerschein dort noch?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Mindestalter Autofahren Schweiz Führerausweis\", \"deutscher Führerschein Schweiz gültig Umtausch\"], \"recency\": \"year\", \"complexity\": \"standard\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2210", "cat": "recipe", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["web", "scholar"], "auto_lenses": false, "library": false, "web": true, "date": "2027-11-18", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n- Science: Write these in English whatever language the question is in: Crossref, arXiv, OpenAlex and PubMed index English titles and abstracts, and a German query returns whatever happened to share a word with it. Use the field's own terminology and name the population, intervention or mechanism. These are bibliographic databases, not a search box.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-11-18. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Kurze Frage: Eier pochieren ohne Essigzusatz, geht das noch vernünftig?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Funktioniert es noch gut, Eier pochieren ohne Essigzusatz im Wasser?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Eier pochieren ohne Essig\", \"pochierte Eier Essig Wirkung Eiweiß gerinnt\", \"poached egg without vinegar technique\"], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2292", "cat": "shopping", "lang": "en", "settings": {"depth": "quick", "queries": 2, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-08-20", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 2 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-08-20. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "best backpack for carrying a laptop and charger to the office, under 100, something that doesnt look like a school bag"}, {"role": "assistant", "content": "{\"standalone_question\": \"Best backpack under 100 for carrying a laptop and charger to the office that does not look like a school bag\", \"answer_shape\": \"table\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"best laptop backpack under 100 office commuter\", \"minimalist laptop backpack under $100 review\"], \"recency\": \"year\", \"complexity\": \"standard\", \"lenses\": [\"web\", \"data\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2302", "cat": "shopping", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["web", "scholar"], "auto_lenses": false, "library": false, "web": true, "date": "2026-05-03", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n- Science: Write these in English whatever language the question is in: Crossref, arXiv, OpenAlex and PubMed index English titles and abstracts, and a German query returns whatever happened to share a word with it. Use the field's own terminology and name the population, intervention or mechanism. These are bibliographic databases, not a search box.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-05-03. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "good budget microphone for podcasting or recording voiceovers at home under 100"}, {"role": "assistant", "content": "{\"standalone_question\": \"What is a good budget microphone under 100 for podcasting or recording voiceovers at home?\", \"answer_shape\": \"table\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"best budget podcast microphone under $100 review\", \"best USB microphone for voiceover home recording 2026\", \"Audio-Technica AT2020 vs Shure MV7 vs Rode PodMic review\"], \"recency\": \"year\", \"complexity\": \"standard\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2320", "cat": "shopping", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-06-05", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-06-05. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Welche Wärmebildkamera fürs Handy oder als Gerät ist für Energieverluste im Haus unter 150 Euro sinnvoll?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Welche Wärmebildkamera unter 150 Euro, als Smartphone-Aufsatz oder als eigenständiges Gerät, eignet sich, um Energieverluste im Haus aufzuspüren?\", \"answer_shape\": \"table\", \"place\": \"\", \"wants_image\": true, \"image_query\": \"thermal imaging camera smartphone attachment\", \"needs_search\": true, \"search_queries\": [\"Wärmebildkamera Smartphone Aufsatz Test unter 150 Euro\", \"Wärmebildkamera Gebäude Energieverlust Test 2026\", \"Wärmebildkamera Auflösung Temperaturempfindlichkeit NETD Vergleich Haus\"], \"recency\": \"year\", \"complexity\": \"research\", \"lenses\": [\"web\", \"data\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2339", "cat": "idiom", "lang": "en", "settings": {"depth": "quick", "queries": 2, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-03-04", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 2 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-03-04. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "what does a good sourdough crumb look like when its properly fermented"}, {"role": "assistant", "content": "{\"standalone_question\": \"What does a good sourdough crumb look like when the dough is properly fermented?\", \"answer_shape\": \"image\", \"place\": \"\", \"wants_image\": true, \"image_query\": \"sourdough bread crumb\", \"needs_search\": true, \"search_queries\": [\"sourdough crumb properly fermented open irregular holes\", \"sourdough bulk fermentation signs crumb structure\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [\"web\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2352", "cat": "idiom", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-03-21", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-03-21. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "wie sieht es mit dem Wasserverbrauch einer Familie mit 4 Personen aus"}, {"role": "assistant", "content": "{\"standalone_question\": \"Wie hoch ist der Wasserverbrauch einer vierköpfigen Familie?\", \"answer_shape\": \"figure\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Wasserverbrauch pro Person pro Tag Deutschland\", \"Wasserverbrauch vierköpfige Familie Liter pro Jahr\"], \"recency\": \"year\", \"complexity\": \"simple\", \"lenses\": [\"web\", \"data\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2391", "cat": "diagram", "lang": "en", "settings": {"depth": "quick", "queries": 2, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-04-10", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 2 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-04-10. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Could you explain the flow of blood through the human heart, naming each chamber and valve in order?"}, {"role": "assistant", "content": "{\"standalone_question\": \"What is the flow of blood through the human heart, naming each chamber and valve in order?\", \"answer_shape\": \"diagram\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"human heart blood flow chambers valves order\", \"heart valves tricuspid mitral pulmonary aortic anatomy\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [\"reference\", \"web\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2398", "cat": "diagram", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-05-31", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-05-31. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Please walk me through how a wastewater treatment plant cleans water, naming each stage in the process."}, {"role": "assistant", "content": "{\"standalone_question\": \"How does a wastewater treatment plant clean water, and what are the stages of the process?\", \"answer_shape\": \"explainer\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"wastewater treatment plant stages primary secondary tertiary\", \"how wastewater treatment works screening sedimentation activated sludge disinfection\", \"municipal wastewater treatment process overview\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [\"web\", \"reference\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2413", "cat": "diagram", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-02-14", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-02-14. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Erkläre mir bitte den Ablauf einer Blutspende in Deutschland: Anmeldung, Voruntersuchung, Spende, Nachsorge – was passiert in jedem Abschnitt?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Wie läuft eine Blutspende in Deutschland ab: Anmeldung, Voruntersuchung, Spende und Nachsorge, und was passiert in jedem dieser Abschnitte?\", \"answer_shape\": \"steps\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Ablauf Blutspende Anmeldung Voruntersuchung Spende Nachsorge\", \"Blutspende Ablauf Deutschland DRK Spendeablauf\", \"Blutspende Voraussetzungen Hämoglobin Spendetauglichkeit Untersuchung\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [\"web\", \"reference\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2464", "cat": "keywords", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-03-09", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-03-09. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "What are good sleep hygiene tips for shift workers?"}, {"role": "assistant", "content": "{\"standalone_question\": \"What are good sleep hygiene tips for shift workers?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"shift work sleep hygiene intervention\", \"night shift workers sleep improvement randomized trial\", \"shift workers circadian misalignment sleep countermeasures\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [\"web\", \"scholar\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2465", "cat": "keywords", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-10-22", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-10-22. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Can you compare Python and JavaScript for beginner programmers?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Compare Python and JavaScript for beginner programmers\", \"answer_shape\": \"comparison\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Python vs JavaScript for beginners\", \"Python JavaScript beginner learning curve comparison\", \"Python vs JavaScript first programming language pros cons\"], \"recency\": \"\", \"complexity\": \"research\", \"lenses\": [\"web\", \"reference\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2482", "cat": "keywords", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-08-05", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-08-05. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Can you explain how vaccines train the immune system?"}, {"role": "assistant", "content": "{\"standalone_question\": \"How do vaccines train the immune system?\", \"answer_shape\": \"explainer\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"vaccine mechanism adaptive immunity memory B cells T cells\", \"vaccine antigen presentation dendritic cells adjuvant mechanism\", \"immunological memory after vaccination antibody response review\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [\"reference\", \"scholar\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2483", "cat": "keywords", "lang": "en", "settings": {"depth": "quick", "queries": 2, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-09-15", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 2 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-09-15. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Which indie games similar to Stardew Valley are worth playing?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Which indie games similar to Stardew Valley are worth playing?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"indie games like Stardew Valley\", \"best farming sim indie games similar to Stardew Valley reviews\"], \"recency\": \"year\", \"complexity\": \"standard\", \"lenses\": [\"web\"], \"facets\": [\"list\"], \"whole_library\": false}"}]}
{"id": "syn-2486", "cat": "keywords", "lang": "de", "settings": {"depth": "deep", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-04-03", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-04-03. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "wie lange dauert ausbildung pflegefachfrau"}, {"role": "assistant", "content": "{\"standalone_question\": \"Wie lange dauert die Ausbildung zur Pflegefachfrau in Deutschland?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Ausbildung Pflegefachfrau Dauer 3 Jahre Pflegeberufegesetz\", \"Pflegefachfrau Ausbildung Teilzeit Dauer Verkürzung\"], \"recency\": \"year\", \"complexity\": \"simple\", \"lenses\": [\"web\"], \"facets\": [\"facts\"], \"whole_library\": false}"}]}
{"id": "syn-2506", "cat": "keywords", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["reference"], "auto_lenses": false, "library": false, "web": true, "date": "2026-05-23", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Reference: Name the subject as an encyclopaedia would title its article: the bare concept, without question words.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-05-23. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "klausur einsicht recht schule nrw"}, {"role": "assistant", "content": "{\"standalone_question\": \"Recht auf Klausureinsicht an Schulen in Nordrhein-Westfalen\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Klausureinsicht Schule NRW Recht\", \"Klausureinsicht Frist Schulgesetz NRW\", \"APO-SI Klausureinsicht Oberstufe NRW\"], \"recency\": \"year\", \"complexity\": \"standard\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2507", "cat": "keywords", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-06-07", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-06-07. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "rezept glutenfreier kuchen schnell"}, {"role": "assistant", "content": "{\"standalone_question\": \"Schnelles Rezept für glutenfreien Kuchen\", \"answer_shape\": \"steps\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"glutenfreier Kuchen schnell Rezept\", \"glutenfreier Rührkuchen einfach 30 Minuten\", \"glutenfreier Kuchen Rezept Mandeln ohne Mehl\"], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [\"web\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2510", "cat": "keywords", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["scholar"], "auto_lenses": false, "library": false, "web": true, "date": "2027-09-11", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Science: Write these in English whatever language the question is in: Crossref, arXiv, OpenAlex and PubMed index English titles and abstracts, and a German query returns whatever happened to share a word with it. Use the field's own terminology and name the population, intervention or mechanism. These are bibliographic databases, not a search box.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-09-11. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Welche Fristen gelten für den Widerspruch gegen einen Steuerbescheid?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Welche Fristen gelten für den Widerspruch (Einspruch) gegen einen Steuerbescheid?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Einspruchsfrist Steuerbescheid Abgabenordnung 355 Monat\", \"Steuerbescheid Bekanntgabe Fiktion drei Tage Einspruch Fristbeginn\", \"Einspruch Steuerbescheid Form Frist Verlängerung Finanzamt\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [], \"facets\": [\"facts\", \"callout\"], \"whole_library\": false}"}]}
{"id": "syn-2514", "cat": "keywords", "lang": "de", "settings": {"depth": "deep", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-05-05", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-05-05. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Wo kann ich eine beglaubigte Geburtsurkunde bestellen?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Wo kann ich eine beglaubigte Geburtsurkunde bestellen?\", \"answer_shape\": \"steps\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"beglaubigte Geburtsurkunde bestellen Standesamt online\", \"beglaubigte Geburtsurkunde Kosten Antrag Voraussetzungen\"], \"recency\": \"year\", \"complexity\": \"standard\", \"lenses\": [\"web\", \"reference\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2548", "cat": "followup", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-02-27", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-02-27. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "why do onions make you cry"}, {"role": "assistant", "content": "Cutting onions releases sulfenic acids, which react with enzymes to form a gas called syn-propanethial-S-oxide. This gas irritates the eyes and triggers tears."}, {"role": "user", "content": "are there any studies on chilling them first"}, {"role": "assistant", "content": "{\"standalone_question\": \"Does chilling onions before cutting reduce eye irritation and tearing?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"chilling onions before cutting lachrymatory factor tearing\", \"refrigerated onion syn-propanethial-S-oxide release study\", \"cold onion cutting eye irritation experiment\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [\"web\", \"scholar\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2552", "cat": "followup", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-05-24", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-05-24. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "how does a mosquito find you"}, {"role": "assistant", "content": "Mosquitoes detect carbon dioxide, body heat, and skin odors like lactic acid from a distance. They combine these cues to home in on a host."}, {"role": "user", "content": "does wearing dark clothes change that"}, {"role": "assistant", "content": "{\"standalone_question\": \"Does wearing dark-coloured clothing change how mosquitoes find a human host?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"mosquito attraction clothing colour dark vs light\", \"mosquito host seeking visual cues dark clothing study\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [\"scholar\", \"web\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2566", "cat": "followup", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-12-01", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-12-01. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "how do you make a simple vinaigrette?"}, {"role": "assistant", "content": "Whisk three parts oil with one part vinegar, then add a pinch of salt, pepper, and a little mustard to help it emulsify."}, {"role": "user", "content": "Compared to store-bought Italian dressing, which one is healthier for someone watching their sugar?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Which is healthier for someone watching their sugar: homemade vinaigrette or store-bought Italian dressing?\", \"answer_shape\": \"comparison\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"store-bought Italian dressing sugar grams per serving nutrition label\", \"homemade vinaigrette sugar content oil vinegar nutrition\", \"Italian dressing added sugar brands comparison\"], \"recency\": \"\", \"complexity\": \"research\", \"lenses\": [\"web\", \"data\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2570", "cat": "followup", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-11-24", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-11-24. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "What's the minimum wage in Ontario right now?"}, {"role": "assistant", "content": "Ontario's general minimum wage is $17.20 per hour as of October 2024. Students and some other workers have a separate, lower rate."}, {"role": "user", "content": "And how much is it for students under 18 who work part time?"}, {"role": "assistant", "content": "{\"standalone_question\": \"What is the Ontario minimum wage for students under 18 who work part time?\", \"answer_shape\": \"figure\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Ontario student minimum wage under 18 part time current rate\", \"Ontario minimum wage students under 18 hours per week 2027\"], \"recency\": \"year\", \"complexity\": \"simple\", \"lenses\": [\"web\", \"data\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2600", "cat": "followup", "lang": "en", "settings": {"depth": "deep", "queries": 3, "sources": ["scholar"], "auto_lenses": false, "library": false, "web": true, "date": "2026-03-11", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Science: Write these in English whatever language the question is in: Crossref, arXiv, OpenAlex and PubMed index English titles and abstracts, and a German query returns whatever happened to share a word with it. Use the field's own terminology and name the population, intervention or mechanism. These are bibliographic databases, not a search box.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-03-11. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "What's a good way to start learning the cello as an adult?"}, {"role": "assistant", "content": "Get a properly sized instrument and a teacher who focuses on posture and bow hold from the start. Short daily practice of 20 minutes beats occasional long sessions."}, {"role": "user", "content": "How do the adult learner dropout rates compare to piano?"}, {"role": "assistant", "content": "{\"standalone_question\": \"How do dropout rates among adult learners compare between cello and piano?\", \"answer_shape\": \"comparison\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"adult music learners dropout rate piano\", \"adult string instrument cello learners discontinuation study\", \"adult beginner music lessons attrition reasons\"], \"recency\": \"\", \"complexity\": \"research\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2654", "cat": "followup", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-06-29", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-06-29. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Ich möchte eine Patientenverfügung schreiben. Muss die notariell beglaubigt werden?"}, {"role": "assistant", "content": "Eine Patientenverfügung muss nicht notariell beglaubigt werden, sie muss aber schriftlich verfasst und unterschrieben sein. Eine notarielle Beurkundung ist optional und erhöht die Verbindlichkeit."}, {"role": "user", "content": "Wer muss die Verfügung überhaupt kennen?"}, {"role": "assistant", "content": "Die Verfügung sollte den Ärzten, Angehörigen und einer Vertrauensperson bekannt sein, damit sie im Notfall berücksichtigt wird. Hinterlegen können Sie sie beim Betreuungsgericht."}, {"role": "user", "content": "Und was passiert, wenn der Arzt die Verfügung ignoriert?"}, {"role": "assistant", "content": "Wenn der Arzt sich über eine wirksame Verfügung hinwegsetzt, kann das eine Straftat oder Körperverletzung darstellen, je nach Lage. Im Zweifel entscheidet ein Betreuungsgericht."}, {"role": "user", "content": "Wie lange gilt so eine Patientenverfügung, muss man die erneuern?"}, {"role": "assistant", "content": "Eine Patientenverfügung gilt unbefristet, sollte aber regelmäßig überprüft und bestätigt werden. Viele Ärzte empfehlen eine Aktualisierung alle zwei bis drei Jahre."}, {"role": "user", "content": "Gibt es Erhebungen, wie viele Menschen in Deutschland tatsächlich eine Patientenverfügung besitzen?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Wie viele Menschen in Deutschland besitzen tatsächlich eine Patientenverfügung? Gibt es Erhebungen dazu?\", \"answer_shape\": \"figure\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Patientenverfügung Deutschland Verbreitung Umfrage Anteil\", \"Patientenverfügung Erhebung Bevölkerung Studie Zentralregister\"], \"recency\": \"year\", \"complexity\": \"standard\", \"lenses\": [\"web\", \"data\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2706", "cat": "followup", "lang": "de", "settings": {"depth": "deep", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-08-28", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2027-08-28. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Wie viel Schlaf braucht ein Erwachsener pro Nacht?"}, {"role": "assistant", "content": "Die meisten Erwachsenen brauchen etwa 7 bis 9 Stunden Schlaf pro Nacht, laut der American Academy of Sleep Medicine."}, {"role": "user", "content": "und bei teenagern wie viel"}, {"role": "assistant", "content": "{\"standalone_question\": \"Wie viel Schlaf braucht ein Teenager pro Nacht?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Schlafbedarf Jugendliche Empfehlung Stunden pro Nacht\", \"sleep duration recommendations adolescents hours per night\"], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [\"web\", \"scholar\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2723", "cat": "followup", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-04-07", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nToday's date is 2026-04-07. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Welche Vorteile hat Linux gegenüber Windows für Entwickler?"}, {"role": "assistant", "content": "Linux bietet meist eine bessere Shell-Unterstützung, native Paketmanager und oft weniger Ressourcenverbrauch. Dafür ist die Treiberunterstützung für manche Hardware schwächer."}, {"role": "user", "content": "Und wie sieht das bei WSL2 aus, gleicht das den Unterschied aus?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Gleicht WSL2 die Vorteile von Linux gegenüber Windows für Entwickler aus?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"WSL2 vs native Linux developer experience limitations\", \"WSL2 Dateisystem Performance Nachteile Entwickler\", \"WSL2 GPU hardware support limitations 2026\"], \"recency\": \"year\", \"complexity\": \"standard\", \"lenses\": [\"web\", \"docs\"], \"facets\": [\"proscons\"], \"whole_library\": false}"}]}
{"id": "syn-2790", "cat": "image_attached", "lang": "en", "settings": {"depth": "deep", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-07-14", "images": 1, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nThe user attached an image to this question, which you cannot see; go by the words. The answer is written\nby a model that sees it. A question about what is in it (describe it, read the text in\nit, explain the chart, solve the exercise, what is wrong with this code) is answered\nfrom the image: needs_search false. Search only when the question needs facts the\nimage cannot show, and then write the queries about what the image shows (the\nproduct, the species, the place by name), never about \"this image\". wants_image is\nfalse unless the user asks to see *other* pictures.\n\nToday's date is 2027-07-14. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Attached is the ingredient label from a protein bar my son eats. There are a lot of words I don't know, can you break down what they are?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Explain what each ingredient on the protein bar label in the attached image means, including the unfamiliar words.\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": false, \"search_queries\": [], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2801", "cat": "image_attached", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-01-21", "images": 1, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nThe user attached an image to this question, which you cannot see; go by the words. The answer is written\nby a model that sees it. A question about what is in it (describe it, read the text in\nit, explain the chart, solve the exercise, what is wrong with this code) is answered\nfrom the image: needs_search false. Search only when the question needs facts the\nimage cannot show, and then write the queries about what the image shows (the\nproduct, the species, the place by name), never about \"this image\". wants_image is\nfalse unless the user asks to see *other* pictures.\n\nToday's date is 2026-01-21. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Sent my tenant's lease scan above. Can you summarize the clause about early termination in plain English?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Summarize the early termination clause in the attached lease scan in plain English\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": false, \"search_queries\": [], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2815", "cat": "image_attached", "lang": "de", "settings": {"depth": "quick", "queries": 2, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2027-11-04", "images": 2, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 2 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nThe user attached 2 images to this question, which you cannot see; go by the words. The answer is written\nby a model that sees them. A question about what is in them (describe it, read the text in\nit, explain the chart, solve the exercise, what is wrong with this code) is answered\nfrom the image: needs_search false. Search only when the question needs facts the\nimage cannot show, and then write the queries about what the image shows (the\nproduct, the species, the place by name), never about \"this image\". wants_image is\nfalse unless the user asks to see *other* pictures.\n\nToday's date is 2027-11-04. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Habe das Teil hier auf dem Flohmarkt gefunden, siehe Foto. Weiß jemand was das ist und ungefähr was sowas wert ist?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Was ist das Teil auf dem Flohmarkt-Foto und was ist es ungefähr wert?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Flohmarkt Fund Wert Schätzung Sammlerwert\", \"gebraucht Verkaufspreis Erfahrungen Sammler Flohmarkt\"], \"recency\": \"year\", \"complexity\": \"standard\", \"lenses\": [\"web\", \"data\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2842", "cat": "image_attached", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["docs"], "auto_lenses": false, "library": false, "web": true, "date": "2026-07-26", "images": 1, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Docs & code: Name the exact API, error message, version or package.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nThe user attached an image to this question, which you cannot see; go by the words. The answer is written\nby a model that sees it. A question about what is in it (describe it, read the text in\nit, explain the chart, solve the exercise, what is wrong with this code) is answered\nfrom the image: needs_search false. Search only when the question needs facts the\nimage cannot show, and then write the queries about what the image shows (the\nproduct, the species, the place by name), never about \"this image\". wants_image is\nfalse unless the user asks to see *other* pictures.\n\nToday's date is 2026-07-26. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Hier der Kassenbon vom Baumarkt, was bedeuten die Abkürzungen hinter den Artikeln?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Was bedeuten die Abkürzungen hinter den Artikeln auf dem Kassenbon vom Baumarkt?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": false, \"search_queries\": [], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2877", "cat": "linked", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": false, "web": true, "date": "2026-07-04", "images": 0, "linked": true}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nThe reader linked a page in the question. It has been read in full and goes to\nthe writer as the main source, so never search for the page itself and never\nput a URL into a search query. Here is how it begins:\n### Proposal: New Playground and Splash Pad for Elm Street Park\nNeighbors have asked for a safer play space for young children for over five years. The proposed $1.2 million project would replace the aging playground with an accessible structure and add a splash pad. The city council votes on funding in March, and public comment is open until the end of the month.\n\nSet needs_search to false when the request is about the page itself:\nsummarising, explaining, translating or assessing what it says, or a question\nthe page answers on its own. Set it to true when the request asks for something\nthe page cannot supply: background, other views, whether its claims hold up,\nwhat happened since. Then write the queries for that part, using the page's\nown subject and names, and rewrite the question so it names the page's subject\ninstead of \"this\" or \"the link\".\n\nToday's date is 2026-07-04. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "is the funding vote really in march or is that outdated? also what do people in the neighbourhood think about it, any opposition? https://www.cityparkscoalition.org/proposal-new-playground-elm-street"}, {"role": "assistant", "content": "{\"standalone_question\": \"Is the city council funding vote on the $1.2 million Elm Street Park playground and splash pad proposal really in March, or is that date outdated? What do neighbours think of the proposal, and is there any opposition?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"Elm Street Park playground splash pad council vote\", \"Elm Street Park playground proposal opposition neighbors\"], \"recency\": \"year\", \"complexity\": \"standard\", \"lenses\": [\"news\", \"web\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2910", "cat": "library", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": [], "auto_lenses": false, "library": true, "web": false, "date": "2026-10-10", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Your papers: These are the person's own papers, mostly in English: write the queries in English, in the field's terminology, one concept or claim per query, the way the papers themselves would phrase it.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nThis is asked against the person's own documents: the papers of their\nliterature project, the files they attached to this chat, or both. The\nsearches run against the pages of these:\n- Park & Oyelaran 2017: Procedural Difficulty Curves in Roguelike Level Design\n- Vasquez & Nowak 2019: Player Motivation Clusters in Free-to-Play Mobile Economies\n- Lindqvist 2015: Attention Mapping in First-Person Shooters Using Eye-Tracking Data\n- Watanabe et al. 2020: Reinforcement Learning Agents as Playtesters for Platformer Balance\n- Feld 2018: Narrative Branching Complexity and Player Retention in Interactive Fiction\n- Berg & Rahman 2021: Haptic Feedback Thresholds in Virtual Reality Combat Systems\n- Okonkwo & Tanaka 2016: Toxicity Detection in Multiplayer Voice Chat Using Acoustic Features\n- Mendes 2022: Gender Representation in Character Creation Interfaces: A Content Analysis\n- Sharpe & Hoffmann 2014: Dynamic Music Adaptation and Physiological Arousal in Horror Games\n- Farouk & Lund 2019: Esports Spectator Engagement Metrics Across Streaming Platforms\n- Petrov & Costa 2023: Serious Games for Rehabilitation: Adherence Patterns in Home-Based Exercise Titles\n- Tan 2018: Emergent Storytelling in Sandbox Simulations: A Taxonomy of Player-Generated Narratives\n- Bellini & Kowalski 2020: Matchmaking Fairness Metrics and Skill Rating Drift in Competitive Games\n- Kim & Ardern 2017: Cognitive Load in Tutorial Design for Complex Strategy Games\n- O'Neill & Haddad 2021: Loot Box Mechanics and Reward Prediction Error: An Experimental Study\n- Gallagher 2013: Immersion and Presence Questionnaires: Reliability Across Game Genres\n- Richter & Lin 2024: Large Language Model Non-Player Characters and Dialogue Coherence in Open-World Games\n- Adjei & Solberg 2022: Accessibility Option Adoption in AAA Titles: A Longitudinal Survey\n\nWrite the search queries so they find passages in these documents: the\nconcepts, methods and terms these titles use, in the language the titles are\nwritten in, whatever language the question is in. A keyword search runs beside\nthe semantic one, and it finds an English paper only through English words.\nSet `whole_library` to true when the request is about the documents as a whole\nrather than a question one passage answers: summarising an attached file or\nsaying what it is about, its key takeaways, main findings or contributions,\nwriting an introduction, a related-work or state-of-the-art section, an\noverview or summary of the literature, a comparison across the papers, which\npapers cover what. Then aim the queries at the main themes they share.\n\nToday's date is 2026-10-10. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "I'm drafting a related-work section on accessibility in games. Could you help me write a paragraph that positions the longitudinal accessibility survey against earlier work?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Help me write a related-work paragraph that positions Adjei & Solberg 2022, the longitudinal survey of accessibility option adoption in AAA titles, against earlier work in the library on accessibility in games.\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"accessibility option adoption AAA games longitudinal survey\", \"earlier surveys of accessibility features in video games\", \"game accessibility options adoption over time\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [], \"facets\": [], \"whole_library\": true}"}]}
{"id": "syn-2913", "cat": "library", "lang": "en", "settings": {"depth": "quick", "queries": 2, "sources": [], "auto_lenses": false, "library": true, "web": false, "date": "2027-09-21", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 2 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Your papers: These are the person's own papers, mostly in English: write the queries in English, in the field's terminology, one concept or claim per query, the way the papers themselves would phrase it.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nThis is asked against the person's own documents: the papers of their\nliterature project, the files they attached to this chat, or both. The\nsearches run against the pages of these:\n- Park & Oyelaran 2017: Procedural Difficulty Curves in Roguelike Level Design\n- Vasquez & Nowak 2019: Player Motivation Clusters in Free-to-Play Mobile Economies\n- Lindqvist 2015: Attention Mapping in First-Person Shooters Using Eye-Tracking Data\n- Watanabe et al. 2020: Reinforcement Learning Agents as Playtesters for Platformer Balance\n- Feld 2018: Narrative Branching Complexity and Player Retention in Interactive Fiction\n- Berg & Rahman 2021: Haptic Feedback Thresholds in Virtual Reality Combat Systems\n- Okonkwo & Tanaka 2016: Toxicity Detection in Multiplayer Voice Chat Using Acoustic Features\n- Mendes 2022: Gender Representation in Character Creation Interfaces: A Content Analysis\n- Sharpe & Hoffmann 2014: Dynamic Music Adaptation and Physiological Arousal in Horror Games\n- Farouk & Lund 2019: Esports Spectator Engagement Metrics Across Streaming Platforms\n- Petrov & Costa 2023: Serious Games for Rehabilitation: Adherence Patterns in Home-Based Exercise Titles\n- Tan 2018: Emergent Storytelling in Sandbox Simulations: A Taxonomy of Player-Generated Narratives\n- Bellini & Kowalski 2020: Matchmaking Fairness Metrics and Skill Rating Drift in Competitive Games\n- Kim & Ardern 2017: Cognitive Load in Tutorial Design for Complex Strategy Games\n- O'Neill & Haddad 2021: Loot Box Mechanics and Reward Prediction Error: An Experimental Study\n- Gallagher 2013: Immersion and Presence Questionnaires: Reliability Across Game Genres\n- Richter & Lin 2024: Large Language Model Non-Player Characters and Dialogue Coherence in Open-World Games\n- Adjei & Solberg 2022: Accessibility Option Adoption in AAA Titles: A Longitudinal Survey\n\nWrite the search queries so they find passages in these documents: the\nconcepts, methods and terms these titles use, in the language the titles are\nwritten in, whatever language the question is in. A keyword search runs beside\nthe semantic one, and it finds an English paper only through English words.\nSet `whole_library` to true when the request is about the documents as a whole\nrather than a question one passage answers: summarising an attached file or\nsaying what it is about, its key takeaways, main findings or contributions,\nwriting an introduction, a related-work or state-of-the-art section, an\noverview or summary of the literature, a comparison across the papers, which\npapers cover what. Then aim the queries at the main themes they share.\n\nToday's date is 2027-09-21. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Can you pull out the passage from the Okonkwo and Tanaka paper that explains how they handled false positives in the toxicity classifier?"}, {"role": "assistant", "content": "{\"standalone_question\": \"How did Okonkwo & Tanaka (2016) handle false positives in their toxicity detection classifier for multiplayer voice chat using acoustic features?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"toxicity detection false positives acoustic features voice chat\", \"Okonkwo Tanaka toxicity classifier false positive handling\"], \"recency\": \"\", \"complexity\": \"simple\", \"lenses\": [], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2914", "cat": "library", "lang": "en", "settings": {"depth": "quick", "queries": 2, "sources": [], "auto_lenses": false, "library": true, "web": false, "date": "2026-07-08", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 2 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Your papers: These are the person's own papers, mostly in English: write the queries in English, in the field's terminology, one concept or claim per query, the way the papers themselves would phrase it.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nThis is asked against the person's own documents: the papers of their\nliterature project, the files they attached to this chat, or both. The\nsearches run against the pages of these:\n- Park & Oyelaran 2017: Procedural Difficulty Curves in Roguelike Level Design\n- Vasquez & Nowak 2019: Player Motivation Clusters in Free-to-Play Mobile Economies\n- Lindqvist 2015: Attention Mapping in First-Person Shooters Using Eye-Tracking Data\n- Watanabe et al. 2020: Reinforcement Learning Agents as Playtesters for Platformer Balance\n- Feld 2018: Narrative Branching Complexity and Player Retention in Interactive Fiction\n- Berg & Rahman 2021: Haptic Feedback Thresholds in Virtual Reality Combat Systems\n- Okonkwo & Tanaka 2016: Toxicity Detection in Multiplayer Voice Chat Using Acoustic Features\n- Mendes 2022: Gender Representation in Character Creation Interfaces: A Content Analysis\n- Sharpe & Hoffmann 2014: Dynamic Music Adaptation and Physiological Arousal in Horror Games\n- Farouk & Lund 2019: Esports Spectator Engagement Metrics Across Streaming Platforms\n- Petrov & Costa 2023: Serious Games for Rehabilitation: Adherence Patterns in Home-Based Exercise Titles\n- Tan 2018: Emergent Storytelling in Sandbox Simulations: A Taxonomy of Player-Generated Narratives\n- Bellini & Kowalski 2020: Matchmaking Fairness Metrics and Skill Rating Drift in Competitive Games\n- Kim & Ardern 2017: Cognitive Load in Tutorial Design for Complex Strategy Games\n- O'Neill & Haddad 2021: Loot Box Mechanics and Reward Prediction Error: An Experimental Study\n- Gallagher 2013: Immersion and Presence Questionnaires: Reliability Across Game Genres\n- Richter & Lin 2024: Large Language Model Non-Player Characters and Dialogue Coherence in Open-World Games\n- Adjei & Solberg 2022: Accessibility Option Adoption in AAA Titles: A Longitudinal Survey\n\nWrite the search queries so they find passages in these documents: the\nconcepts, methods and terms these titles use, in the language the titles are\nwritten in, whatever language the question is in. A keyword search runs beside\nthe semantic one, and it finds an English paper only through English words.\nSet `whole_library` to true when the request is about the documents as a whole\nrather than a question one passage answers: summarising an attached file or\nsaying what it is about, its key takeaways, main findings or contributions,\nwriting an introduction, a related-work or state-of-the-art section, an\noverview or summary of the literature, a comparison across the papers, which\npapers cover what. Then aim the queries at the main themes they share.\n\nToday's date is 2026-07-08. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Is there anything in the library about serious games for physical therapy that reports adherence rates above 60 percent?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Does the library contain any paper about serious games for physical therapy or rehabilitation that reports adherence rates above 60 percent?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"serious games rehabilitation adherence rate\", \"home-based exercise adherence exergame physical therapy\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [], \"facets\": [\"stats\"], \"whole_library\": false}"}]}
{"id": "syn-2918", "cat": "library", "lang": "en", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": true, "web": true, "date": "2026-11-08", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Your papers: These are the person's own papers, mostly in English: write the queries in English, in the field's terminology, one concept or claim per query, the way the papers themselves would phrase it.\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nThis is asked against the person's own documents: the papers of their\nliterature project, the files they attached to this chat, or both. The\nsearches run against the pages of these:\n- Park & Oyelaran 2017: Procedural Difficulty Curves in Roguelike Level Design\n- Vasquez & Nowak 2019: Player Motivation Clusters in Free-to-Play Mobile Economies\n- Lindqvist 2015: Attention Mapping in First-Person Shooters Using Eye-Tracking Data\n- Watanabe et al. 2020: Reinforcement Learning Agents as Playtesters for Platformer Balance\n- Feld 2018: Narrative Branching Complexity and Player Retention in Interactive Fiction\n- Berg & Rahman 2021: Haptic Feedback Thresholds in Virtual Reality Combat Systems\n- Okonkwo & Tanaka 2016: Toxicity Detection in Multiplayer Voice Chat Using Acoustic Features\n- Mendes 2022: Gender Representation in Character Creation Interfaces: A Content Analysis\n- Sharpe & Hoffmann 2014: Dynamic Music Adaptation and Physiological Arousal in Horror Games\n- Farouk & Lund 2019: Esports Spectator Engagement Metrics Across Streaming Platforms\n- Petrov & Costa 2023: Serious Games for Rehabilitation: Adherence Patterns in Home-Based Exercise Titles\n- Tan 2018: Emergent Storytelling in Sandbox Simulations: A Taxonomy of Player-Generated Narratives\n- Bellini & Kowalski 2020: Matchmaking Fairness Metrics and Skill Rating Drift in Competitive Games\n- Kim & Ardern 2017: Cognitive Load in Tutorial Design for Complex Strategy Games\n- O'Neill & Haddad 2021: Loot Box Mechanics and Reward Prediction Error: An Experimental Study\n- Gallagher 2013: Immersion and Presence Questionnaires: Reliability Across Game Genres\n- Richter & Lin 2024: Large Language Model Non-Player Characters and Dialogue Coherence in Open-World Games\n- Adjei & Solberg 2022: Accessibility Option Adoption in AAA Titles: A Longitudinal Survey\n\nWrite the search queries so they find passages in these documents: the\nconcepts, methods and terms these titles use, in the language the titles are\nwritten in, whatever language the question is in. A keyword search runs beside\nthe semantic one, and it finds an English paper only through English words.\nSet `whole_library` to true when the request is about the documents as a whole\nrather than a question one passage answers: summarising an attached file or\nsaying what it is about, its key takeaways, main findings or contributions,\nwriting an introduction, a related-work or state-of-the-art section, an\noverview or summary of the literature, a comparison across the papers, which\npapers cover what. Then aim the queries at the main themes they share.\n\nToday's date is 2026-11-08. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Which papers in this set look at gender representation or character creation, and are there any that compare across countries?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Which papers in the library look at gender representation or character creation, and do any of them compare across countries?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"gender representation character creation interfaces content analysis\", \"character customization gender cross-national comparison games\", \"avatar creation cultural differences player gender representation\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [\"scholar\"], \"facets\": [], \"whole_library\": true}"}]}
{"id": "syn-2945", "cat": "library", "lang": "de", "settings": {"depth": "quick", "queries": 2, "sources": [], "auto_lenses": false, "library": true, "web": false, "date": "2027-07-16", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 2 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Your papers: These are the person's own papers, mostly in English: write the queries in English, in the field's terminology, one concept or claim per query, the way the papers themselves would phrase it.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nThis is asked against the person's own documents: the papers of their\nliterature project, the files they attached to this chat, or both. The\nsearches run against the pages of these:\n- Hartmann & Brandt 2016: Mental Accounting and Household Budget Allocation: Evidence from German Panel Data\n- Odendaal & Weber 2019: Present Bias in Retirement Savings Decisions Among Young Adults\n- Raman & Koch 2018: Financial Literacy Interventions and Debt Repayment Behavior: A Randomized Field Experiment\n- Lindqvist & Feld 2021: Buy-Now-Pay-Later Credit and Overspending: A Survey Study of Online Shoppers\n- Okafor & Hoffmann 2017: Emergency Savings Buffers and Resilience to Income Shocks in Low-Wage Households\n- Brenner et al. 2020: Default Enrollment Effects in Employer-Sponsored Pension Plans: A Cross-Country Comparison\n- Kessler 2022: Algorithmic Robo-Advice and Investor Trust: Experimental Evidence on Portfolio Recommendations\n- Renner & Adler 2023: Financial Stress, Cognitive Bandwidth, and Money Management Decisions Under Scarcity\n\nWrite the search queries so they find passages in these documents: the\nconcepts, methods and terms these titles use, in the language the titles are\nwritten in, whatever language the question is in. A keyword search runs beside\nthe semantic one, and it finds an English paper only through English words.\nSet `whole_library` to true when the request is about the documents as a whole\nrather than a question one passage answers: summarising an attached file or\nsaying what it is about, its key takeaways, main findings or contributions,\nwriting an introduction, a related-work or state-of-the-art section, an\noverview or summary of the literature, a comparison across the papers, which\npapers cover what. Then aim the queries at the main themes they share.\n\nToday's date is 2027-07-16. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "ok also insgesamt was sind so die wichtigsten ergebnisse aus der ganzen sammlung? gibt halt viel zu lesen"}, {"role": "assistant", "content": "{\"standalone_question\": \"Was sind die wichtigsten Ergebnisse aus der gesamten Sammlung der Papers zu Haushaltsfinanzen, Sparen, Schulden und Finanzentscheidungen?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"main findings household finance savings debt present bias mental accounting\", \"default enrollment financial literacy buy-now-pay-later emergency savings robo-advice experimental evidence\"], \"recency\": \"\", \"complexity\": \"research\", \"lenses\": [], \"facets\": [], \"whole_library\": true}"}]}
{"id": "syn-2956", "cat": "library", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": true, "web": true, "date": "2027-07-20", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Your papers: These are the person's own papers, mostly in English: write the queries in English, in the field's terminology, one concept or claim per query, the way the papers themselves would phrase it.\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nThis is asked against the person's own documents: the papers of their\nliterature project, the files they attached to this chat, or both. The\nsearches run against the pages of these:\n- Hartmann & Greve 2019: Formative Feedback Loops in Blended Mathematics Classrooms: A Mixed-Methods Study\n- Yilmaz et al. 2021: Teacher Digital Competence and Its Relation to Student Engagement in Lower Secondary Schools\n- Brandt 2017: Learning Analytics Dashboards and Self-Regulated Learning in Vocational Education\n- Weiß et al. 2020: Inclusive Classroom Practices and Peer Interaction: A Longitudinal Analysis in German Primary Schools\n- Sørensen & Fischer 2022: Gamified Vocabulary Learning in Secondary Foreign Language Instruction: Effects on Retention and Motivation\n- Krämer & Lindner 2023: Comparing Teacher Professional Learning Communities Across Three European Countries: A Multilevel Approach\n\nWrite the search queries so they find passages in these documents: the\nconcepts, methods and terms these titles use, in the language the titles are\nwritten in, whatever language the question is in. A keyword search runs beside\nthe semantic one, and it finds an English paper only through English words.\nSet `whole_library` to true when the request is about the documents as a whole\nrather than a question one passage answers: summarising an attached file or\nsaying what it is about, its key takeaways, main findings or contributions,\nwriting an introduction, a related-work or state-of-the-art section, an\noverview or summary of the literature, a comparison across the papers, which\npapers cover what. Then aim the queries at the main themes they share.\n\nToday's date is 2027-07-20. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Ich schreibe gerade meine Masterarbeit über Feedback im Matheunterricht und habe nur noch wenig Zeit. Kannst du mir kurz sagen, welche Rolle formative Rückmeldungen in der Studie von Hartmann und Greve spielen und welche Effektstärken sie gefunden haben?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Welche Rolle spielen formative Rückmeldungen in der Studie von Hartmann & Greve (2019) zu Formative Feedback Loops in Blended Mathematics Classrooms, und welche Effektstärken wurden gefunden?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"formative feedback loops blended mathematics classrooms\", \"formative feedback effect size mathematics mixed-methods study\", \"Hartmann Greve formative feedback blended mathematics effect size\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [\"scholar\"], \"facets\": [\"stats\"], \"whole_library\": false}"}]}
{"id": "syn-2957", "cat": "library", "lang": "de", "settings": {"depth": "deep", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": true, "web": true, "date": "2026-05-02", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Your papers: These are the person's own papers, mostly in English: write the queries in English, in the field's terminology, one concept or claim per query, the way the papers themselves would phrase it.\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nThis is asked against the person's own documents: the papers of their\nliterature project, the files they attached to this chat, or both. The\nsearches run against the pages of these:\n- Hartmann & Greve 2019: Formative Feedback Loops in Blended Mathematics Classrooms: A Mixed-Methods Study\n- Yilmaz et al. 2021: Teacher Digital Competence and Its Relation to Student Engagement in Lower Secondary Schools\n- Brandt 2017: Learning Analytics Dashboards and Self-Regulated Learning in Vocational Education\n- Weiß et al. 2020: Inclusive Classroom Practices and Peer Interaction: A Longitudinal Analysis in German Primary Schools\n- Sørensen & Fischer 2022: Gamified Vocabulary Learning in Secondary Foreign Language Instruction: Effects on Retention and Motivation\n- Krämer & Lindner 2023: Comparing Teacher Professional Learning Communities Across Three European Countries: A Multilevel Approach\n\nWrite the search queries so they find passages in these documents: the\nconcepts, methods and terms these titles use, in the language the titles are\nwritten in, whatever language the question is in. A keyword search runs beside\nthe semantic one, and it finds an English paper only through English words.\nSet `whole_library` to true when the request is about the documents as a whole\nrather than a question one passage answers: summarising an attached file or\nsaying what it is about, its key takeaways, main findings or contributions,\nwriting an introduction, a related-work or state-of-the-art section, an\noverview or summary of the literature, a comparison across the papers, which\npapers cover what. Then aim the queries at the main themes they share.\n\nToday's date is 2026-05-02. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Ich bin Doktorandin und soll nächste Woche einen Überblick über die ganze Sammlung geben. Was sind die Kernergebnisse der sechs Arbeiten insgesamt, so in ein paar Stichpunkten?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Was sind die Kernergebnisse der sechs Arbeiten in meiner Sammlung insgesamt, in Stichpunkten?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"formative feedback learning analytics self-regulated learning\", \"teacher digital competence student engagement lower secondary\", \"gamification vocabulary retention motivation inclusive classroom peer interaction\"], \"recency\": \"\", \"complexity\": \"research\", \"lenses\": [\"scholar\"], \"facets\": [], \"whole_library\": true}"}]}
{"id": "syn-2962", "cat": "library", "lang": "de", "settings": {"depth": "quick", "queries": 2, "sources": ["auto"], "auto_lenses": true, "library": true, "web": true, "date": "2027-05-25", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 2 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Your papers: These are the person's own papers, mostly in English: write the queries in English, in the field's terminology, one concept or claim per query, the way the papers themselves would phrase it.\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nThis is asked against the person's own documents: the papers of their\nliterature project, the files they attached to this chat, or both. The\nsearches run against the pages of these:\n- Hartmann & Greve 2019: Formative Feedback Loops in Blended Mathematics Classrooms: A Mixed-Methods Study\n- Yilmaz et al. 2021: Teacher Digital Competence and Its Relation to Student Engagement in Lower Secondary Schools\n- Brandt 2017: Learning Analytics Dashboards and Self-Regulated Learning in Vocational Education\n- Weiß et al. 2020: Inclusive Classroom Practices and Peer Interaction: A Longitudinal Analysis in German Primary Schools\n- Sørensen & Fischer 2022: Gamified Vocabulary Learning in Secondary Foreign Language Instruction: Effects on Retention and Motivation\n- Krämer & Lindner 2023: Comparing Teacher Professional Learning Communities Across Three European Countries: A Multilevel Approach\n\nWrite the search queries so they find passages in these documents: the\nconcepts, methods and terms these titles use, in the language the titles are\nwritten in, whatever language the question is in. A keyword search runs beside\nthe semantic one, and it finds an English paper only through English words.\nSet `whole_library` to true when the request is about the documents as a whole\nrather than a question one passage answers: summarising an attached file or\nsaying what it is about, its key takeaways, main findings or contributions,\nwriting an introduction, a related-work or state-of-the-art section, an\noverview or summary of the literature, a comparison across the papers, which\npapers cover what. Then aim the queries at the main themes they share.\n\nToday's date is 2027-05-25. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Ich muss für ein Seminar erklären, warnm Gamification im Fremdsprachenunterricht überhaupt funktioniert. Gibt es in der Sammlung was dazu, speziell zu Behalten von Vokabeln?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Warum funktioniert Gamification im Fremdsprachenunterricht, und speziell für das Behalten von Vokabeln?\", \"answer_shape\": \"explainer\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"gamified vocabulary learning retention motivation foreign language\", \"gamification mechanisms motivation second language vocabulary acquisition\"], \"recency\": \"\", \"complexity\": \"standard\", \"lenses\": [\"scholar\", \"web\"], \"facets\": [], \"whole_library\": false}"}]}
{"id": "syn-2969", "cat": "library", "lang": "de", "settings": {"depth": "balanced", "queries": 3, "sources": ["auto"], "auto_lenses": true, "library": true, "web": true, "date": "2027-09-02", "images": 0, "linked": false}, "messages": [{"role": "system", "content": "You triage questions for a research assistant.\n\n**Default to searching.** This is a research tool; the user came here instead of\nasking a chatbot precisely because they want sourced, current answers, and your\ntraining data has a cutoff you cannot see past.\n\nSet needs_search to false only when the request is one of these:\n  - a greeting, thanks, or small talk;\n  - rewriting, translating, summarising or formatting text the user pasted;\n  - arithmetic, or reasoning about code or data the user supplied;\n  - a question about this conversation itself.\n\nEverything else needs a search, including anything about software, APIs,\ndocumentation, tools, companies, people, events, prices, laws, science or\nhealth, and every \"how do I…\", \"what is…\" and \"why does…\" about the world. When\nin doubt, search.\n\nSet `wants_image` to true when a picture is part of the answer:\n  - the reader asks to see the thing: \"what does X look like\", \"show me X\",\n    \"wie sieht X aus\", \"Bild von X\", when X is something with an appearance;\n  - the question is about a person, a brand, a product, a place, a building\n    or landmark, an animal or plant, a vehicle, an artwork, a flag or a logo:\n    the reader recognises these by sight, so the picture identifies them.\nLeave it false when there is nothing to look at: a concept, a mechanism, a\nlaw, a standard, a protocol, an event, a price or figure, a how-to, advice.\n\"Wie sieht es mit X aus\" and \"what does a good X look like\" are idioms about\na situation or a standard, not requests for a picture.\n\nWhen `wants_image` is true, write `image_query`: the subject as an image\narchive would caption it, a few words in English, the name and nothing else\n(\"okapi\", \"flag of Argentina\", \"Eiffel Tower\", \"Porsche 911\"). Otherwise\nleave it empty.\n\nAnything the user wants to see needs a search, because a picture can only be\nshown if a search returned one. Describing it in words instead is not\nanswering it.\n\nRewrite the question so it stands on its own without the conversation: resolve\n\"it\", \"they\", \"that version\" against the history. Keep the user's language.\n\nIf a search is needed, write up to 3 search queries: keyword queries a\nsearch engine would answer well, not sentences. Make them cover different angles\nof the question, never restatements of each other. If no search is needed, return\nan empty list.\n\nThe searches run against these corpora, so phrase the queries for them:\n- Your papers: These are the person's own papers, mostly in English: write the queries in English, in the field's terminology, one concept or claim per query, the way the papers themselves would phrase it.\n- Web: Short keyword queries, the way you would type them into a search box.\n\nThe reader left the choice of corpora to you. Set `lenses` to the one or two\nthat actually hold the answer. A third is almost always the general web\nanswering the same query twice:\n  - \"web\": Web, General search across several independent engines.\n  - \"scholar\": Science, Peer-reviewed papers and preprints: PubMed, arXiv, Crossref, OpenAlex.\n  - \"news\": News, Newswires and established newsrooms, for anything still developing.\n  - \"docs\": Docs & code, Official documentation, standards and source: MDN, GitHub, Stack Overflow.\n  - \"reference\": Reference, Encyclopaedias and definitions, for concepts and background.\n  - \"data\": Data, Computed figures: prices, conversions, statistics, with their as-of date.\n\n\"web\" is where most questions are answered and the one to fall back on when none\nof the tests below fits. \"news\" for something happening now, \"docs\" for an API or\na library, \"reference\" for who or what something is, \"data\" for a price, a rate\nor a quantity.\n\nAdd \"scholar\" (*alongside* \"web\", not instead of it) whenever the question has\nan answer somebody has measured: whether something works, how well, how safely,\nat what dose, by what mechanism, what causes what, how large the effect is. That\ncovers medicine, nutrition, psychology, biology, climate, materials and the\nsocial sciences, and it holds however casually the question is put. \"Bringt\nKreatin was\", \"ist Süßstoff schädlich\" and \"warum wirkt Koffein bei mir nicht\nmehr\" all have an evidence base, and the layperson asking is exactly the reader\nwho cannot find it without you. Answer them from the studies rather than from a\nsupplement shop's summary of them. Where a research literature plausibly exists,\nadd it: \"web\" + \"scholar\" is one search, and the two are ranked against each\nother rather than in isolation.\n\nLeave it out where research has no stake: a price, a company's plans, an API, a\nrecipe, a legal deadline, what happened yesterday. A subject that merely sounds\nserious does not qualify. The test is whether the thing being asked about has\nbeen studied, not whether it is important.\n\nWhen \"scholar\" is among the corpora, write the search queries in English and in\nthe field's own terminology, naming the population, the intervention or the\nmechanism. Crossref, PubMed, arXiv and OpenAlex index English titles and\nabstracts, and a German query returns whatever happened to share a word with it.\nThe general engines answer an English query perfectly well, so this costs the web\nnothing. One query may stay in the reader's language when the question is also\nabout something local, such as a national guideline or a product sold there.\n\n\nSet `recency` when the answer depends on the current state of the world: a\nchange, a release, a price, an ongoing event, or any question containing \"now\",\n\"latest\", \"today\", \"this year\" or a current year, including their equivalents\nin the user's language, such as \"heute\", \"aktuell\" or \"dieses Jahr\" in German.\nUse the *widest* setting that still sharpens the answer, because the three narrow\nones are not preferences. \"day\", \"week\" and \"month\" are filters at the search\nengine: everything older is missing from the response entirely and cannot be\nranked back in. Reserve them for questions where a source from outside the window\nwould be worthless: a breaking event, an active story, a figure that moves by\nthe day.\n\n\"year\" is the mild one. It excludes nothing; it asks the ranking to put recent\nsources first. That makes it the right answer for the large middle ground: a\nquestion that is *about* the current state of something, where a two-year-old\npage might still be the one that answers it. Leave it empty for settled subjects,\nwhere an old source is as good as a new one: a definition, a mechanism, a\nhistorical fact, anything whose best evidence is a paper rather than a page.\n\nWhat you must never do is reach for \"month\" to express \"fairly recent\". That\ndeletes the 2005 paper, the standard's original text, and the explanation that\nhas been correct for a decade, and the answer is then written from whatever\nhappened to be published lately.\n\nSet `complexity` to how much research the question actually needs. This decides\nhow wide the search goes and how many pages are read, so judge the *question*,\nnot how interesting the subject is:\n  - \"simple\" when one good source settles it: a price, a date, a score, a\n    definition, a version number, a forecast, \"who is X\", \"when did Y happen\".\n  - \"standard\" for anything that needs a few sources read and weighed against\n    each other. This is the default when none of the tests below is met.\n  - \"research\" when *any* of these is true, however briefly the question is\n    put: it names two or more things to compare or choose between; it asks what\n    the evidence, the studies or the state of research say; it has several\n    distinct parts that each need their own sources; or it asks for the overall\n    picture of a field. One matching test is enough, and the question can be\n    very short: \"Vergleiche A, B und C\" is research in five words, and so is\n    \"was sagt die Studienlage zu X\". Asking what the research says means the\n    answer has to survey it. Length alone never is: a long question about one\n    thing is still standard.\n\nSet `answer_shape` when the answer has a better container than a paragraph,\nso it can be laid out rather than written as prose:\n  - \"figure\" for one current value: a share price, an exchange rate, a\n    population, the temperature right now, \"how much/many is X\".\n  - \"series\" for one quantity across time: a price over months, a\n    population by decade, a temperature by year. Three points at least.\n  - \"table\" for several entities compared on the same attributes:\n    league standings, three tools rated on the same criteria.\n  - \"comparison\" for exactly two things weighed against each other:\n    \"X vs Y\", \"should I use X or Y\". Use \"table\" for three or more.\n  - \"steps\" for an instruction or a process the reader is meant to\n    follow: \"how do I install X\", \"how do I apply for Y\". Only when\n    the sources give the actual steps, in order.\n  - \"weather\" for conditions at a place: the temperature now, today, or\n    a forecast for the coming days. Put the bare place name in `place`.\n  - \"match\" for one fixture between two teams or countries: a result, a\n    scoreline, an upcoming game. Use \"table\" instead for a whole round\n    or a league table.\n  - \"profile\" for one named thing the question asks *about* and wants\n    identified: a person, an organisation, a brand, a product, a place, a\n    building, an animal or plant species, a piece of software, a standard:\n    \"who is X\", \"what is the company Y\", \"was ist Z\", \"wer ist Z\". The\n    test is that the answer opens by saying what the thing is; a question\n    that merely mentions it, or that asks how to use it or whether to buy\n    it, is not a profile. Neither is a concept, a\n    mechanism or a piece of jargon: \"was ist ein Autoencoder\" wants the\n    idea taught, which is \"explainer\", and a card of facts about an idea\n    is a card with nothing on it.\n  - \"image\" when the answer is something to *look at*: what a flag, a\n    logo, an animal, a building or a painting looks like. The question\n    is usually \"what does X look like\", \"show me X\", \"wie sieht X aus\".\n  - \"diagram\" when the answer is a structure or a process with named\n    parts and the relationships between them: how a request flows\n    through a system, how a cycle works, what causes what. Only when the\n    sources actually describe the parts and their connections; never to\n    decorate a definition. Choose \"explainer\" instead when the reader\n    wants the subject taught rather than mapped; that shape draws the\n    same picture when there is one to draw.\n  - \"explainer\" when the reader is asking to *understand* something\n    rather than to be told a fact about it: how a mechanism works, why\n    something happens, what a concept or a piece of jargon actually\n    means. \"Wie funktionieren Autoencoder\", \"warum ist der Himmel blau\",\n    \"explain transformers\", \"was bedeutet Impedanz\". The test is that a\n    correct one-line answer would leave the reader no wiser, they asked\n    because the subject is unfamiliar, not because they mislaid a fact.\n    A question that merely opens with \"what is\" and wants a named thing\n    identified is \"profile\", and a procedure the reader is meant to\n    carry out is \"steps\". Not an explainer either: how events unfolded\n    (\"wie kam es zu X\", \"was ist seit 2022 passiert\", \"Geschichte von\n    X\"), a set of things to list (\"welche Nebenwirkungen\"), or a\n    decision to weigh (\"lohnt sich X\"). Those are prose, with `facets`.\n\nLeave it empty for everything else. A three-row table explaining a concept\nis worse than the sentence it replaced, and a diagram of a definition is\nworse still: a shape is chosen because the answer has that form, never\nbecause the subject sounds like it should.\n\nWhen `answer_shape` is empty, `facets` may name the parts of the answer\nthat are structure rather than argument, so they can be laid out in a\npanel above the prose. Most important first, at most three:\n  - \"facts\" for the key attributes of the subject as label and value,\n    dates, sizes, owners, versions, places, where the reader would\n    otherwise scan a paragraph for them.\n  - \"stats\" for one to four headline numbers the answer turns on, each\n    with its unit and its date.\n  - \"timeline\" for events in order, how something came about, what\n    happened when. Three dated events at least.\n  - \"proscons\" for arguments on both sides, advantages and drawbacks,\n    \"is X worth it\", \"lohnt sich X\", \"should I\".\n  - \"list\" for a set of distinct named things the reader would look up\n    one by one: the side effects of a drug, the documents an application\n    needs, the alternatives to a product. Each item has a name of its\n    own, and there are three at least. Reasons, causes, factors, tips\n    or the points of an explanation are not a list, they are the\n    argument, and belong in the prose.\n  - \"grid\" for a few items on the same two to four attributes when that\n    is only part of the answer; when the table *is* the answer, use the\n    \"table\" shape instead.\n  - \"callout\" for the one caveat the reader must not miss, a deadline, a\n    safety note, the common mistake.\n\nLeave `facets` empty for most questions, and always when `answer_shape` is\nset. Name a facet only when the sources will state that structure, an answer\nthat is one explanation or one argument has none, and a panel that merely\nrepeats the prose is noise. The usual matches: a history or a sequence of\nevents is \"timeline\", a decision is \"proscons\", side effects, required\ndocuments or named alternatives are \"list\", a subject with key data is\n\"facts\". \"Why does X happen\" or \"how does X work\" names no facet: its\nparts are steps of one argument, and a list of them is worse than prose.\n\nThis is asked against the person's own documents: the papers of their\nliterature project, the files they attached to this chat, or both. The\nsearches run against the pages of these:\n- R. et al. 2017: Maillard Reaction Kinetics in Low-Moisture Baked Goods\n- K. & J. 2019: Sensory Profiling of Fermented Vegetable Brines Across Three Production Methods\n- Y. & D. 2015: Starch Retrogradation and Staling in Long-Term Stored Bread\n- C. et al. 2020: Consumer Acceptance of Insect-Based Protein Ingredients in Home Cooking\n- T. & P. 2018: Sous-Vide Cooking Time-Temperature Models for Pork Shoulder Tenderness\n- B. & K. 2021: Traditional Cassava Fermentation and Microbial Succession in Rural Households\n- L. & N. 2016: Emulsion Stability of Plant-Based Mayonnaise Analogues Under Thermal Stress\n- H. & K. 2022: Machine Learning Prediction of Flavor Compound Pairings from Recipe Corpora\n- M. & S. 2014: Salt Reduction Strategies in Commercial Cheese Production\n- I. & A. 2019: Home Food Waste Behaviour: A Survey of Household Meal Planning Practices\n- F. & G. 2023: Olive Oil Oxidation Markers During Repeated Deep-Frying\n- R. et al. 2018: Umami Synergy Between Glutamate and Nucleotides in Dashi Broth Extraction\n- J. & E. 2020: Gluten-Free Dough Rheology: Hydrocolloid Substitution and Viscoelastic Behaviour\n- P. & C. 2017: Cooking Oil Choice and Cardiovascular Risk Perception Among Urban Consumers\n- L. & D. 2024: Chef Decision-Making Under Ingredient Scarcity: A Qualitative Study of Restaurant Kitchens\n\nWrite the search queries so they find passages in these documents: the\nconcepts, methods and terms these titles use, in the language the titles are\nwritten in, whatever language the question is in. A keyword search runs beside\nthe semantic one, and it finds an English paper only through English words.\nSet `whole_library` to true when the request is about the documents as a whole\nrather than a question one passage answers: summarising an attached file or\nsaying what it is about, its key takeaways, main findings or contributions,\nwriting an introduction, a related-work or state-of-the-art section, an\noverview or summary of the literature, a comparison across the papers, which\npapers cover what. Then aim the queries at the main themes they share.\n\nToday's date is 2027-09-02. Treat anything you remember as potentially out of date."}, {"role": "user", "content": "Was sind die Hauptergebnisse der Sammlung zur Lebensmittelsicherheit beim Fermentieren zu Hause?"}, {"role": "assistant", "content": "{\"standalone_question\": \"Was sind die Hauptergebnisse der Sammlung zur Lebensmittelsicherheit beim Fermentieren zu Hause?\", \"answer_shape\": \"\", \"place\": \"\", \"wants_image\": false, \"image_query\": \"\", \"needs_search\": true, \"search_queries\": [\"home fermentation food safety microbial succession\", \"fermented vegetable brine microbial safety production methods\", \"traditional fermentation households pathogen contamination control\"], \"recency\": \"\", \"complexity\": \"research\", \"lenses\": [], \"facets\": [], \"whole_library\": true}"}]}