DASH:GenUpload a web log with an IP address in it, or a German sales export with a PLZ column, and the dashboard you get back says where — sessions by country and city, revenue by Bundesland — even though your file never had those columns.
The platform keeps a few small lookup tables on the server. When it recognises a column it can resolve, it looks every value up and adds the answers as ordinary columns before the AI agents design anything. From that point on they are columns like any other: charted, filtered, shown in the data table, and cross-filtered when you click one.
It costs nothing. No extra AI call is made, no Coins are spent, and the whole thing can be switched off for a run — or for the whole deployment.
What it recognises today
| Your column holds | You get | Example |
|---|---|---|
| An IP address | Country, country code, region, city | 203.0.113.7 → United States · California · San Francisco |
| A German postal code | Bundesland, its code, Ort | 80331 → Bayern · DE-BY · München |
| A country code or name | The country's English name, its ISO code, the continent | DEU, Deutschland, Германия → Germany · DE · Europe |
The new columns are named after the column they came from, so two of them never collide: client_ip becomes client_ip_country, client_ip_city; PLZ becomes PLZ_bundesland, PLZ_ort.
If your file already has a column saying the same thing — a Bundesland column of your own — that one is left alone and no second one is added. Yours wins.
How a column is recognised
Two things have to agree, and then a third decides.
- The name.
client_ip,Client IP Address,PLZ,Postleitzahl,ZIP,Post Code,Country— matched word by word, never as a fragment.zipis a postal code;descriptionis not an IP address. - The values. They have to look like the thing: a real IPv4 or IPv6 address, four or five digits for a German postal code.
- How many are actually found. This is what separates a German postal code from an American ZIP — both are five digits, and only one of them is in the table.
An IP address is the one exception to the first rule: nothing else looks like an address, so a column of them is recognised whatever it is called.
Every file is checked, not just the largest. When you upload several files at once — the Power BI case — the postal code is usually in the small one: a customers file next to a ledger of a hundred thousand rows. Each file is recognised on its own and gets its own columns, and the limit on how many columns one file may gain applies to each of them separately.
What you see before anything runs
Drop a file in and the source card shows a chip per recognised column:
client_ip→ Country, Region, City
Hover it for three worked examples from your own file (80331 → Bayern) and how much of the column was found. Click it to switch that table off for the next run. Nothing to switch on: it is already on, which is the point.
Switching it off
- One chip — click it in the source card.
- One run — send
enrich=noneto the API (see the API reference). - Some tables only —
enrich=plz-de, a comma-separated list of names fromGET /api/v1/references.
The three targets
The web page (HTML) gets it by default. The columns are embedded in the file with everything else, so filters, cross-filtering and the data table work offline like the rest.
Power BI gets it by default when the data travels inside the artifact. The geography columns are categorised in the model — Country, State or Province, City — so Power BI Desktop's map visuals place them without you touching the model. With linked data, where the report reads your own file from a folder at refresh time, nothing is joined: that file does not have the columns, and a report built on them would break the first time you refreshed it.
Apache Superset only when you ask. Its bundle does not carry data — the dashboard queries a table in your database — so a dashboard naming columns your table does not have would be broken on arrival. Ask for it with enrich=plz-de, and the bundle carries the enriched table beside the dashboard, with a note saying to load that file instead of the one you uploaded.
Versions of a dashboard
A dashboard remembers which tables it was built with. Restyle it, change a chart, or rebuild it from next month's file, and it reads the same columns — even if the server's tables have been refreshed since, and even if one has been removed (the columns are then simply empty).
Changing which tables are joined changes which columns the design may use, so it only travels with a new instruction: the dashboard has to be designed again around the new vocabulary.
Accuracy, and what to know before sharing
City-level geolocation is approximate. It is accurate to a metro area at best and is not an address. Every dashboard that uses it says so on its Notes tab.
An IP address is personal data. Looking it up does not put anything in the file that was not already there — your raw column is still in it — but the dashboard now also says where that person was. Before sharing such a dashboard by link, consider removing the raw address column from your upload; the looked-up columns work without it.
Attribution travels with the data. The tables are published under licences that require it, so each dashboard's Notes tab names the source. Please leave it in place.
Where the answers come from
| Table | Source | Licence |
|---|---|---|
| Postal codes | GeoNames | CC-BY 4.0 |
| Country names | Unicode CLDR | Unicode-3.0 |
| IP geolocation | DB-IP Lite | CC-BY 4.0 |
GET /api/v1/references lists what a deployment has installed, with each table's version. Nothing is ever fetched while your dashboard is being built: the tables are files on the server, refreshed on a schedule by whoever runs it, which is why the whole platform still works with no internet connection at all.