How we work

Votara shows how Switzerland got here, vote by vote, and how the country could look in 2050 depending on the next decisions. These rules apply to every page.

1. Every number has a source

Each figure links to its dataset in the data ledger: publisher, table, date of the last download, licence and known limits. A figure without a source is not shown. The data behind each chart can be downloaded as a CSV file.

2. Facts and opinions are kept apart

Official figures carry the label "Official figure". Votara's own calculations carry the label "Votara estimate, not an official forecast". Scenarios carry the label "What-if, not a forecast". Results from Votara users carry the label "Opinion of Votara users, not a representative poll".

3. Three answers, treated the same way

For each problem, Votara shows one answer from the left, one from the centre and one from the right. Each answer is drawn from party documents, consultation replies or parliamentary business and links to its origin. Until a camp has reviewed its text, the card says that Votara editors wrote it. The three cards look the same, and their order changes. Details are in section 15.

4. Gaps are shown

When no reliable estimate exists, the page says "No reliable estimate". Votara does not fill gaps with guesses.

5. Rates and long series

Where a total alone can mislead, Votara also shows rates (per 1,000 residents or per cent) and long time series.

6. Nationality, not ethnicity

Switzerland does not record ethnicity. Votara uses nationality, country of birth and migration status, and says so on the page concerned.

7. Headlines state the number

Headlines say what the data shows. They do not judge it.

8. Press as context

Next to selected charts, Votara lists articles from several outlets, regions and languages: title, outlet, date and link. Votara copies no article text.

9. Corrections are public

Every correction is dated and listed on the Corrections page.

10. Votara's own work is labelled

The odds model, the problem tree and the summaries of party positions are Votara's work. They are listed in the data ledger as Votara entries.

11. Privacy by default

Under the Federal Act on Data Protection (FADP), political opinions are sensitive personal data. Votara collects as little data as possible. This version of the site has no user accounts and stores no opinions. Details are in the privacy policy.

12. Safeguards before features

Features that carry legal or personal risks are published only together with their safeguards.

13. Four languages

German, French, Italian and English have the same status. When a translation is missing, the page says so.

14. Open code and data

The code is licensed under AGPL-3.0 and the editorial texts under CC BY 4.0. Each dataset keeps the licence of its source, listed in the data ledger.

15. How the three voices are written

Votara editors write the three answers on the sub-problem pages of the problems.

• Sources. Only the parties' own documents (programmes, position papers, press releases), their replies to federal consultations, and parliamentary business in Curia Vista (motions, postulates, parliamentary initiatives). Each card links to its source. If no source has been found for a camp, the card says "No source found yet" and stays empty.
• Rules. At most 80 words per answer, quotes of at most 10 words, a similar length for the three answers. A card lists only parties of its camp whose own document states the position.
• Review. Each card says "Written by Votara editors from" with a link to the source, until the camp has reviewed its text. After a review, the card says "Reviewed by" and who reviewed it. No card has been reviewed so far.
• Order. The order of the three cards changes every day. It depends only on the sub-problem and the date in Zurich: everyone sees the same order on the same day, and no cookie is needed. Over three days in a row, each camp comes first once.
• Camps. Left: SP and Greens. Centre: Die Mitte and GLP. Right: SVP and FDP. This grouping is an editorial choice by Votara. The left–right placement comes from the Selects 2023 election study (FORS, Lausanne, in German). On its scale from 0 (left) to 10 (right), FDP candidates place themselves at 7.0, Die Mitte candidates at 5.5 and SVP candidates at 8.3 (PDF page 67), and the study calls FDP and SVP «die beiden bürgerlichen Parteien». The same study counts the FDP in the political centre when it adds up seats by camp (PDF page 9). The grouping is therefore Votara's choice, not a finding of the study. It also gives each camp two parties.

16. Votara estimates

Votara's own calculations carry the label "Votara estimate, not an official forecast". Today these are:

• Chance that a federal vote is accepted ("odds-lite"). A logistic regression learns from past federal votes how the result went together with what was known before the vote: the type of vote, the recommendations of the Federal Council and the parliament, the final votes in both chambers, and the party recommendations weighted by the parties' vote shares at the previous National Council election. It uses no polls. The method page shows a test on past votes: for each year, the model only knew the votes before it, and its scores are compared with three simple rules such as "follow the Federal Council". Votara does not publish estimates for upcoming votes yet. The first publication needs an editorial sign-off; until then, a setting in the code keeps every such estimate out of the pages and out of the data sent to the browser. Once published, no new estimate appears in the 48 hours before a vote, and each published estimate is compared with the result on the scoreboard. Odds for the three population scenarios do not exist yet.
• My commune in 2050 (commune pages). The OFS/BFS publishes no population scenarios for communes. Votara applies the growth of the canton's reference scenario to each of its communes: population 2050 ≈ population of the commune in the latest year × canton scenario 2050 ÷ canton scenario of that year. The page shows the formula, every input and the tag "canton-level scenario applied proportionally".
• Density (The space). People per km² = population ÷ area, on the total area and on the area without lakes, rivers, rock and glaciers (OFS/BFS land use statistics).
• "Where could everyone live?" (The space). Population of the OFS/BFS reference scenario for 2050 ÷ settlement areas of the latest survey. The calculation assumes that the settlement areas stay as surveyed. A table shows the same calculation for the low and the high scenario.
• Changes in daily life (Daily life, then and now). The change between the first and the latest published value: in per cent for levels, in percentage points for rates.

Code and inputs are in the data ledger, for example under votara-odds-lite and votara-commune-projection.

17. What-if switches

On The track, each scheduled federal vote has a switch: Yes, No or Undecided. A switch moves the what-if curve only if the vote has an impact estimate. An impact estimate states:

• what it measures: the population in 2050, in persons;
• the difference from the OFS/BFS reference scenario in 2050 if the vote ends Yes, and if it ends No;
• who made it, for example the Federal Council in its message or the authors of a study;
• a link to the source.

The difference grows in a straight line from the year of the vote to 2050, and the differences of several switches add up. The curve carries the label "What-if, not a forecast", and the page lists each assumption with its author and source.

None of the votes scheduled today has an impact estimate. Each switch therefore shows "No reliable estimate: this switch does not move the curve." Votara does not fill this gap with its own guess.

18. Data

• Ledger. Each dataset has an entry in the data ledger: publisher, address of the data, licence, date of the last download, the steps Votara applies and the known limits.
• Every night. An automatic job downloads the sources again. For each one it saves the raw file, writes the processed table and, if the data changed, records the date of the download in the ledger. It then checks all ledger entries and opens a pull request (a proposed change in the code repository) that lists, per dataset, whether the data changed. An editor reviews the change before it is accepted; the job never changes the site by itself. A night without new data produces no pull request. If a download fails, the job stops without a pull request. Accepted changes reach the site with the next deployment.
• Verified. "Verified" in the ledger means: the data was downloaded from the official address, and at least one value was compared with a separate official publication. The entry records the date, the method and the value checked. Entries without this check say "Not verified yet".