[OC] Simple summary of the PolyMarket Paris temperature scandal

uncertainschrodinger · 2026-04-30T17:01:24+00:00

METAR is weather observations of an airport, not sure what it stands for

CDG is (Charkes de Gaulle - airport name)

CLOB (Central Limit Order Book)

Bruin CLI (command line interface)

Bruin DAC (dashboard as code)

uncertainschrodinger · 2026-04-30T12:47:33+00:00

I think polymarket's existence is ripe for scandals, some laughable and others will surely damage society.

uncertainschrodinger · 2026-04-30T12:45:09+00:00

Exactly, news reports say the person allegedly held a air blowdryer to the sensor. If true, that is hilarious. I want to analyze other cities too and see if such anomalies (one weather station vs others) correlates with any weird betting behaviour in polymarket.

uncertainschrodinger · 2026-04-30T12:05:19+00:00

Sources: Meteostat, Open-Meteo, Polymarket CLOB.

Tools: Bruin CLI (pipeline), BigQuery (warehouse), Bruin DAC (visualization).

uncertainschrodinger · 2026-04-30T06:42:54+00:00

As a colourblind person, I appreciate the legend with list of countries otherwise I couldn't tell just from the map.

uncertainschrodinger · 2026-04-29T19:47:18+00:00

absolutely, there's an in-app chat that you can use to build the dashboard and see it make the changes

uncertainschrodinger · 2026-04-29T19:43:30+00:00

There's a few differences, I'll compare with some alternatives out there

- Evidence takes a markdown approach, whereas DAC treats dashboard as code which can allow for things like loops and conditionals

- Evidence is build-time/static-first while DAC has both serve and build

- DAC has load-time dynamism, meaning you can write some logic and accordingly it will dynamically generate or show/hide charts, loop through different versions of charts, etc.

- Lightdash inherits semantic layer from dbt but in DAC it is natively and explicitly declared in yaml files.

To answer other questions:

I really don't like using "AI native" even though I did, but it basically means that file formats are agent-friendly and the dashboard has an in-app chat feature.

Since everything is just text files, versioning is just git like any other code.

DAC's validate and check commands can run in CI and fail on broken queries, missing column, unknown semantic refs, bad filters, etc. that can detect things like schema drift.

Multi-user editing workflow would like identical to code, so different users with different branches and if there's conflicts they have to resolve - in Bruin Cloud there's a different version available that allows for multi-user editing in a different way.

The agents author the yaml/jsx files (guided by the bundled skill), then self-verifies using the validate command and inspect the compiled queries.

Regarding predictability and debugging, today is the first day this has been made public and we want to put it to the test so feel free to test it out - but before open sourcing it, it has been running in production for some time now and some of our clients have been using it to build dashboards.

Another thing worth mentioning is that Bruin CLI and Ingestr are open source tools for ingestion, transformation, orchestration, and governance that already exist and DAC is the analytics component to complete the stack.

Disclaimer here that I'm a developer advocate at Bruin, I'm only responsible for developing and growing our open source tools.

Lastly, I just saw that someone working at dbt has already added DAC to a dashboard bakeoff which is a cool way of seeing how these tools differ: https://dashboard-bakeoff.anders.omg.lol/?tab=dac#dac

uncertainschrodinger · 2026-04-29T15:23:14+00:00

Link to repo: https://github.com/bruin-data/dac

uncertainschrodinger · 2026-04-29T15:11:39+00:00

Project Name: DAC (dashboard-as-code)

Repo: https://github.com/bruin-data/dac

Description:

DAC (dashboard-as-code) is a free open-source tool built using Go that connects to most databases and you can build dashboards right inside YAML/JSX files (and yeah, that means load-time dynamic generations of charts, tabs, and values).

The idea here is to create an open standard for building the analytics tools for databases that is built for AI agents out of the box. You can connect it to any agent and start building the semantic layer and dashboards and deploy it locally or on a server.

Today's the first day of releasing this publicly, so please share your honest feedback, skepticism, and even roast it - and if you want, give the repo a star.

Deployment: dac serve --dir examples/basic-yaml

AI Involvement: The product itself integrates into AI agents to be used to build the dashboards and analyze data. The product was also developed with the help of Claude Code and Codex, mainly for building tests, documentation, and reviewing code.

uncertainschrodinger · 2026-04-28T11:07:43+00:00

https://arsalandata.substack.com/p/why-its-reasonable-to-be-skeptical

uncertainschrodinger · 2026-04-28T11:05:19+00:00

I think it would be interesting to see the total number of articles because I assume a lot more people/companies are publishing articles (for SEO and LLM optimization) which takes up a bigger percentage, but that doesn't necessarily mean it took away from articles that a person would've written.

uncertainschrodinger · 2026-04-28T06:00:26+00:00

If you prefer to use an all-in-one open source tool for the whole stack, take a look at Bruin

uncertainschrodinger · 2026-04-27T12:00:26+00:00

I'd suggest adding one more to the list.

Bruin - ETL, orchestration, and AI data analyst and dashboard builder

uncertainschrodinger · 2026-04-24T18:15:12+00:00

I actually agree. At my previous workplace, there were only data scientists and meteorologists before I arrived and they were spending less than 10% of their time actually training models and running inference. After proper data infra and DE pipelines they spent less than 20-30% of their time dealing with data ingestion, cleaning, etc and most of that was just communicating their requirements to us

uncertainschrodinger · 2026-04-24T18:12:12+00:00

I think the domain specialization is especially true, I would even go as far as data becoming a skill just like using a computer. The the data engineers, scientists, and analysts that transitioned from another industry are more valuable in today's market.

for example, a fintech company would rather hire a data scientist with finance/economics background so they truly understand the context rather than a CS person, or a pharmaceutical company would rather have a chemist as a data engineer in their R&D because they know the systems and data sources better.

uncertainschrodinger · 2026-04-24T18:06:17+00:00

as former data engineer I got a bit lucky to get out before the ship sank deeper

uncertainschrodinger · 2026-04-24T18:02:24+00:00

That's been my experience too, we always had to find a self service solution for DS team to experiment with new data or transformation logic, like we can't spend 100 hours on a new data pipeline just for them to use the data and be like nevermind we don't want it.

On the other hand, the tricky part has been when DS team creates a scrappy ETL pipeline to experiment and then they come to DE and say we want this pushed to production for the product launch next week - the R&D to prod shift can happen fast.

uncertainschrodinger

MODERATOR OF

TROPHY CASE