flow_audiences
ChatGPTReturns the audiences one version of one brand names, and whether a panel stands behind each. The two counts differ on purpose: 'listed' is how many were written, 'measured' is how many have a panel size behind them. Reporting the first as though it were the second presents unfinished work as finished. An unmeasured audience carries whyNotMeasured, which says which of three things happened — the panel has no question for what the reading rests on, every definition covers so much of the market that it is the market, or too few respondents fall inside it. Those are three different answers and none of them is 'not done yet'. Pass a 'name' (partial match is fine) for one audience in full: its constructs, the cross-section ladder step by step, and the profile rows with their indices.
flow_claim_detail
ChatGPTReturns one claim in full: what would have to be true for it to be wrong, what was checked against it, and the sub-questions that were actually searched — each with its answer and its citations. Also carries second-order signal where it was gathered: what people write on forums, what they search for, what they say under videos. A null there means that signal was not gathered for this claim, not that it was gathered and found nothing. Theme ids belong to a version — the same claim rebuilt in a later run is a different row with a different id.
flow_claim_evidence
ChatGPTReturns what the claims of one version were read out of, gathered by domain: how many citations, how many distinct sources behind them, and which domains carry the most. Narrow to one claim with themeId. Two counts of the domains are reported because the page records them in two places and they do not agree: domainsRecorded is what the claims name as read, domainsWithACitation is what a URL is still held for. The gap is what the page chose to keep, not missing research. It also states plainly what it cannot do. No citation on this path carries a publication date, so how old the evidence is cannot be answered here — 'age' comes back null to say so out loud rather than leaving a domain breakdown to read as though age had been checked. Merged claims are left out, since they are carried by another claim and their evidence would be counted twice.
flow_entry_points
ChatGPTReturns the situations this version says are worth entering on — the step between a claim about the market and an audience. The unit of work downstream is a moment paired with an audience, not an audience on its own. Each carries its motive, the insight underneath it, whether it is adjacent to something the brand already owns or asks the market to do something new, and what it is chosen instead of. 'evidenceUnder' reports how the claims below it fared in the evidence check: a moment is built from themes whether or not they passed, so it can rest on a claim that did not hold. That is not removed — the choice is strategic — but it has to be visible. Earlier versions did not have this step at all, so an empty answer can mean the step had not been built yet rather than that no moment was found; the tool says which.
flow_inputs
ChatGPTReturns what the client actually sent — briefs, comment documents, spreadsheets, meeting notes — in the order it arrived. A requirement is a conclusion; these are what it was drawn from. Each carries the version it first appeared in, because a version shows what reached it: an input that arrived later is deliberately absent from an earlier one. 'brandSpecific' false means the input belongs to the client rather than to this brand — the shared workbook, the playbooks — and applies to every brand under it. Having a filename does not make an input brand-specific. Ask with an inputId for one in full, including its body and, where the original is not in English, the English rendering kept beside it rather than replacing it.
flow_market_claims
ChatGPTReturns the claims about the market that one version of one brand stands on, grouped by the strategy that found each. A theme is a claim about how the market behaves, not a finding about the brand, and each one carries what it was checked against: an evidence grade, the verdict of the evidence check, how many sources it was read from, and its momentum. Two fields repay attention. 'serves' lists the brief requirements the claim answers; 'breaks' names a requirement it violates — the work found something the brief said to stay away from, and it is kept rather than dropped so the disagreement is visible. 'mergedFrom' counts how many independent readings arrived at the same claim: one reached four times by four different strategies is a stronger thing than one reached once. Filter with 'variant' for a single strategy, or 'onlyVerified' for claims that passed the evidence check. Ask flow_claim_detail with an id for what was searched and what came back.
flow_media_plan
ChatGPTReturns the media step: the point where a measurement becomes a decision. Each card reads downward — what was measured about those people, what that suggests activating, and the reason underneath, written out so it can be argued with. That is the difference between a suggestion and a guess. There are TWO generations and they are not interchangeable. Later versions carry a card per audience and channel; earlier ones carry one allocation for the whole brand, read alongside the measured audiences. The answer names which generation the version has, and never presents one as a summary of the other. budgetShare is a percentage of the non-TV budget, not an amount. Each card also carries what was considered and set aside, and what the constraint cost — a plan without its rejected options reads as the only option. A brand with neither generation says so: the step may not have been built for that brand yet while other brands in the same version have it.
flow_overview
ChatGPTReturns the map of the Predict Flow work: which brands exist, which versions the client can currently see, which of those is published and which are previews, and for every brand and version how much each step actually holds. Call this first — every other flow tool takes a brand and a version, and the ids come from here. Two counts are reported as pairs on purpose. Questions are drafted for every strategy but only some are searched, so 'written' and 'searched' differ, and only the second says what was investigated. Audiences are written before they are measured, so 'listed' and 'measured' differ, and only the second has a panel size behind it. The media step also names its generation: earlier versions carry one whole-brand plan, later ones a card per audience and channel instead — they are not interchangeable and one does not substitute for the other. Only versions currently offered to the client appear here. Earlier ones still exist but are no longer served, which is different from their being empty.
flow_questions
ChatGPTReturns what was asked, grouped by the way of asking. A strategy is an altitude (the category, the product, or a moment) crossed with a stance (looking for what we do not know, testing what we believe, or arguing against a habit); '-HR' asks in Croatian on Croatian sources. Without a strategy named, the overview only: questions are written for EVERY strategy because that costs only our own model, while searching costs money and a subset runs. 'written' and 'searched' are different numbers and only the second says what was investigated. Name a strategy and its questions come with it: what each asks, which requirements it serves, how many citations came back, and the sub-questions it was broken into with their answers truncated. A sub-question with zero citations was searched and came back with nothing, which is a finding rather than a gap. A strategy that was not searched carries empty counts that are not results at all, and the answer says which case it is.
flow_requirement_coverage
ChatGPTAnswers 'did the research reach what the brief asked for'. For each requirement reference it reports how many themes cite it, which themes contradict it, whether the client marked it key, and whether the brief itself answered it. Counted per reference rather than per brief row: one reference can carry several rows, because the brief was read out of several inputs that each said something about the same field. A gap means no theme names that reference. It does not mean the requirement was ignored — a theme can be about a requirement without citing it — so read a gap as 'nothing is linked here', not as 'nothing was done'. themesBreaking is the column worth reading first: a claim that contradicts a requirement is kept rather than dropped, so the disagreement reaches the room instead of being quietly resolved. Gaps are listed first, key ones among them first of all. Pass onlyGaps to see nothing else.
flow_requirements
ChatGPTReturns the numbered requirements one version of one brand has to answer — the brief, read out of everything the client sent and broken into referenced rows. Each row carries its reference (BR or RR), the brief field it sits in, what it asks, whether the client marked it as key, and whether anything about it is unsettled: contested, corroborated, disputed, or superseded by a later input. Rows are compact by default. Ask again with a single 'reference' for one requirement in full, including the client's own words, the dated input it came from, and what it feeds downstream. Filter with 'slot' for one brief field, or 'onlyKey' for the requirements the client singled out — the rest still apply, but questions and themes go deeper on the key ones. Different versions can be built against different brief contracts, so a reference valid in one version may not exist in another. The tool says so rather than returning nothing.
flow_search
ChatGPTFinds a term across the steps of one brand or of every brand on the deployment: requirements, claims, audiences, moments, questions, inputs and the citations underneath the claims. Each hit says which step and which version it is in, shows the words around the match rather than the opening sentence, and carries exactly what to call next to read that row in full. Results are capped per step per brand so one noisy step cannot crowd out the others, and matchedByScope reports how many there really were — 'nothing in the requirements' stays visible next to two hundred citation hits. It matches text, not meaning, and it does not search the web. A claim can be about a subject without using the word for it, so an empty answer is about wording rather than about the work — and it says that instead of implying the subject was not studied.
flow_social_sources
ChatGPTReturns the social sources gathered for this client — forums, Reddit, video, and the rest — with how many articles came from each and the most recent few by name and URL. A count is not a source: '39 articles' tells a reader nothing they can check, so the articles travel with the row. These are the SOCIAL sources only. The page keeps no editorial source list, so an absence here is not evidence that nothing editorial was read. Sources belong to the client rather than to one brand, so every brand under this client reports the same list.
flow_strategy_choice
ChatGPTReturns which ways of asking were taken into the search for one version of one brand, which were set aside, and the reason written out on both sides. Questions are drafted for every strategy because that costs only our own model; searching costs money, so a subset runs. This tool is that decision — flow_questions is what came back from it. The half worth reading is the one set aside. A strategy dropped for breaking one of the brief's own constraints is the brief being honoured; one dropped for returning nothing solid is a finding about the market, not an omission. Also carries what the brief itself called for, which is what the choice was judged against, and flags any disagreement between the strategies chosen and the ones actually searched. Versions that searched every strategy they wrote carry no choice at all, and the tool says that rather than returning an empty list.
flow_summary
ChatGPTEverything settled so far in one answer: how much of the brief is covered, how many ways of asking were actually searched, how many claims hold, how many audiences a panel stands behind, which moments were chosen, and which generation of the media step this version carries. Composed from the other steps rather than read from one of its own — the page builds this step the same way, so no figure here exists only in this answer and every one of them can be checked against the tool it came from. Read the pairs as pairs: strategies written against searched, audiences listed against measured, themes total against verified. The first of each is what was produced; the second is what stands behind it. Carries the named things too, not only the counts — the key requirements, the strongest verified claims, the measured audiences with their sizes, and the moments. A summary of numbers alone is not something anyone can act on.
flow_trace
ChatGPTWalks backwards from one claim, or from one audience, to the numbered requirements behind it, the client's own words that asked for them, and the input those words arrived in. This is the answer to 'why is this here' — not our reasoning about it, but the quoted sentence someone sent us and the dated file it came in. Every reading of a requirement is returned, not the first: a reference can be read out of several inputs that each said something different about the same field. The last hop is honest about itself. A brief row names its source as a line of prose, not as a key, so the input is found by matching an input's title inside that line — it resolves to exactly one input for almost every row, and where it resolves to none or to several the chain stops there and says so rather than choosing. The requirement hop above it is a real reference and is exact. A claim can also name a reference this version's brief does not carry, which is reported rather than silently dropped.
flow_version_diff
ChatGPTCompares two versions the client can currently see and reports what appeared, what left and what stayed across requirements, themes, audiences and entry points — with the names, not only the counts. Compared by the name each thing carries: a requirement's reference, a theme's claim, an audience's or a moment's name. Not by database id, because ids belong to a version and the same claim rebuilt in a later run is a different row — comparing ids would report every single thing as replaced. A reworded claim therefore shows as one gone and one added, which is the honest reading of a rewrite. Only versions currently offered can be compared. When just one is offered there is nothing to compare, and the tool says that rather than returning an empty result — it answers on its own once a preview sits beside the published version.
get_categorization_taxonomy
ChatGPTReturns the active LLM categorization taxonomy — the list of top-level content categories used to classify articles and sources. Response shape: { version, categories: [{ name, description }] }. Use the 'name' values when assigning a category to content; if no category fits, assign 'Others' (handled by the caller, not returned by this tool).
get_countries
ChatGPTReturns all countries that have intelligence data available. Response shape: { countries: [{ id, name }] }. Use the 'id' value as idCountry when calling search_trends or get_raw_search_analysis to restrict results to a specific country. Call this first when the user mentions a country by name and you need to resolve it to an ID.
get_current_user
ChatGPTReturns the profile of the account this connection is authenticated as: id, name, username, country, user type, and role. Call this tool when you need to know who the authenticated caller is before making user-specific queries.
get_my_topics
ChatGPTReturns the personalized trending topics for the authenticated user's account, aggregated over a chosen time window. Topics are pre-selected based on the user's industry profile and past engagement. Use 'type' to choose the aggregation window: Daily (last 24 h), Weekly (last 7 days), Monthly (last 30 days). Call this when an LLM needs to surface what is trending specifically for this user or their organization.This reads the intelligence archive belonging to the connected account, which is built up over time. An account that has not accumulated one yet gets an empty result, and that is an answer rather than a failure.
get_object
ChatGPTReturns FULL detail for one pilots object: headline, paragraph, full source mix, activation, and all references.
get_raw_search_analysis
ChatGPTReturns raw scoring data for intelligence analyses matching the given filters. Unlike search_trends, results are not semantically re-ranked — they expose the underlying searchScore and trendScore values directly. Use this when you need raw signal data, score comparisons, or when building your own ranking on top of the platform scores. Accepts the same filters as search_trends (searchTerm, industry, country, date range).This reads the intelligence archive belonging to the connected account, which is built up over time. An account that has not accumulated one yet gets an empty result, and that is an answer rather than a failure.
get_source_industries
ChatGPTReturns all active source industries (type = SourceIndustry). Response shape: { industries: [{ id, name }] }. Use the 'id' value as idSourceIndustry when calling search_trends or get_raw_search_analysis to restrict results to a specific industry. Call this first when the user mentions an industry by name and you need to resolve it to an ID.
list_objects
ChatGPTLists LIGHT object cards for one scope tab, paginated. Use get_object for full detail (references, headline, paragraph, sources, activation) on a single object.
list_projects
ChatGPTLists the caller's pilots tenant projects. The tenant is resolved from the credential you connected with: the workspace chosen when you authorised this connection, or the account an API key belongs to. Pass tenant only for local/dev testing.
list_scopes
ChatGPTLists a pilots project's real scopes (category tabs) plus metadata. Call list_projects first if you don't already know which project to use.
list_sources
ChatGPTLists a pilots project's sources (id, name, engine, url/keywords, fallback chain). An empty list is a real answer, not a failure: a project can be scored from search and trend signals alone, and those register no sources. Read it as 'this project has no editorial corpus', not as 'the sources could not be loaded'.
search_trends
ChatGPTSearches the trends and intelligence analysis database using semantic search. Provide a natural-language search term describing the topic you are investigating — the platform converts it to vector embeddings and returns the most relevant trend analyses. Each result includes a title, summary, keywords, audience insights, recommended content templates, and the source articles that make up the trend cluster. Use idSourceIndustry (obtained from get_source_industries) to restrict results to a specific industry. Use dateFrom / dateTo (YYYY-MM-DD) to scope results to a time window. Results are ranked by semantic relevance score. Call this tool when an LLM needs to discover trending topics, market signals, or content ideas for a given domain.This reads the intelligence archive belonging to the connected account, which is built up over time. An account that has not accumulated one yet gets an empty result, and that is an answer rather than a failure.
flow_audiences
Claudeflow_claim_detail
Claudeflow_claim_evidence
Claudeflow_entry_points
Claudeflow_inputs
Claudeflow_market_claims
Claudeflow_media_plan
Claudeflow_overview
Claudeflow_questions
Claudeflow_requirement_coverage
Claudeflow_requirements
Claudeflow_search
Claudeflow_social_sources
Claudeflow_strategy_choice
Claudeflow_summary
Claudeflow_trace
Claudeflow_version_diff
Claudeget_categorization_taxonomy
Claudeget_countries
Claudeget_current_user
Claudeget_my_topics
Claudeget_object
Claudeget_raw_search_analysis
Claudeget_source_industries
Claudelist_objects
Claudelist_projects
Claudelist_scopes
Claudelist_sources
Claudesearch_trends
Claude
