← Terms and policies

How your notes become research

Version 0.3 (draft), 24 September 2026. Draft for review, not yet in force. Changes since 0.2: whose project this is, that it is separate from any thesis, your own institution's rules, and the reason the dataset is meant to be shared (`open-questions.md`, decisions 2, 9 and 11). On 25 September, the contact address filled in.

For everyone taking notes in Bracket at COP31. terms-of-use.md is the agreement; privacy-notice.md is the data protection detail. This is the part about the research itself: what your notes are for, what you get out of it, and what happens when the dataset leaves the team.

Reading this is not the same as agreeing to it. Accepting the terms, the privacy notice and the acceptable-use rules is a condition of using Bracket. This document is not. Taking part in the study yourself, as a subject rather than an observer, is optional, it is shown separately, it never blocks anything, and you can withdraw it later: a consent you cannot decline would not be a consent. What is recorded when you decide either way is which version of this document you had in front of you.

What we are doing

Bracket studies how negotiations proceed inside UNFCCC meetings: what is said, by which delegation, about which paragraph of which text, and with what effect on the progress of the negotiation. That question cannot be answered from the published record, because the published record is the outcome and not the process. It can only be answered by people in the rooms, taking notes the same way, at the same time, about the same things.

You are that method. Your notes are not background colour for somebody else's argument: they are the observations the analysis is computed from.

Whose project this is. Bracket is a research programme of its own, led by Matthew Winkler as an independent researcher, who is the data controller (privacy-notice.md §1). The hosting accounts are held and paid by his company, Odd Analytics SASU, on his behalf; the company pays the invoices and decides nothing about the data. The programme is separate from any thesis, Matthew's own doctoral thesis included, and no thesis is its home: the affiliation on a paper is each author's own, never the dataset's.

What happens to a note

  1. You type it in the room. It is saved on your device, then synced.
  2. It carries what you gave it: the delegation, the tactic tags, the text and paragraph cited, the speaker turn it was typed under, and the time.
  3. The owner reads it, alongside everyone else's for the same meeting.
  4. Tagged notes become counts: how often a tactic appears, by whom, on which agenda item, and how that lines up with what the text did next.
  5. Quotations may appear in a paper. Attributed to a delegation, never to a named individual (see terms-of-use.md §6), and never with your identity attached to a delegation's conduct unless you are an author of the piece and agree to it.

The coding you do is data, not admin. A tactic tag you marked "candidate" stays a candidate in the dataset; it is not silently promoted. Where the team disagrees about a tag, the disagreement is itself a finding, which is why calibration exists and why we measure it.

Credit and authorship

The default is that people who did the work are named. Nobody's fieldwork is absorbed anonymously into a single-author paper.

We use CRediT, the NISO contributor taxonomy, to record what each person actually did. For most of the team the fieldwork contributions are:

  • Investigation: taking notes in meetings. Everyone who observed.
  • Data curation: reviewing your own notes, tagging, calibration.
  • Methodology and Formal analysis: the coding scheme and the analysis.
  • Writing, review and editing: anyone who reads and improves a draft.

How that turns into an author list:

  • Authorship on the main papers follows the ICMJE idea applied to our field: a substantial contribution to the work, plus involvement in drafting or critically revising, plus approval of what is submitted. Fieldwork plus engagement with a draft earns authorship. Fieldwork alone earns a named acknowledgement and a CRediT statement, and an invitation to engage with the draft so that it becomes authorship if you want it.
  • The author order and the specific list for each paper are proposed by the lead author and circulated to everyone who contributed to that paper, before submission, with time to object.
  • A dataset that is published is cited as a work in its own right, with its own DOI and its own author list, which includes the observers. If the dataset is used by somebody else, the dataset citation is how you get credit.
  • Your own work. You may use your own notes in your own thesis or paper, including quotations, provided you cite the project, do not name individuals, and tell the owner before submission so that two papers do not make the same claim from the same data in different words. The owner does not get authorship on your paper by default for having built the tool.
  • Your own institution's rules. Check them before you use your notes in your own work. Some universities ask for ethics approval or a data management plan for any research with human participants, whoever runs the study. The project has no ethics committee: its papers describe the safeguards instead, and this set of documents will be deposited under a DOI at version 1.0, so that you, or a committee, can cite exactly what the team worked under.

[DECISION: whether a short written authorship agreement is circulated before the COP, naming the planned papers and who leads each. Recommended: it is much easier before the fieldwork than after.]

How the dataset may be published

The intention is that the dataset is archived and, in time, published, as far as that can be done responsibly. The reasons: a process dataset of this kind does not exist, and any funder the programme has in future will expect its data to be shared.

Three states, in order:

  1. Inside the team. As now. Notes private to author and owner.
  2. Shared with co-authors and named collaborators, under the data management plan, as a pseudonymised export. This is the state most analysis happens in.
  3. Archived or published in a repository ([DECISION: which. Zenodo is the realistic answer for an independent researcher and is where open-questions.md leans]), under access conditions decided then. A fully open release of note text is not assumed and may well not happen; an open release of the counts, the tags and the structure, without the note text, is realistic.

No publication of the dataset happens without telling the team first and giving you a chance to object to the inclusion of your own notes.

How pseudonymisation works at export

An export is a zip of tidy tables with a codebook, run by the owner and recorded permanently.

You are always a label. Every export, of either kind, replaces your identity with "Researcher 001", "Researcher 002" and so on. The number comes from the order people first wrote a note at that event, so it follows the fieldwork rather than the order accounts happened to be created, and it is the same label every time, so a figure in one paper can be matched with a figure in another.

Pseudonymised. The default, and what leaves the team. Each researcher is a label with their role and position, and nothing else: no name, no organisation, no account id. Background details are never included. Edit history is never included, because it holds earlier wordings and device identifiers. Reflections, which are your own thinking and the most identifying thing you write, are left out by default. Notes from closed sessions have their text removed by default while keeping the tags and delegations.

Identified. For the project's own analysis, and only by a deliberate choice recorded in the export itself. It carries the same labels and adds the columns that identify you: account id, name, organisation, badge type, and the background details of people who ticked the consent box on their research profile. The codebook of every export says which of the two it is, on its first page.

This is pseudonymisation, not anonymisation, and the documents say so rather than pretending otherwise. The labels are stable because a key exists and the owner holds it. On top of that, with 30 to 50 people a label plus a role plus a position plus the list of meetings somebody attended can identify a colleague to another colleague with no key at all. So a pseudonymised export is still personal data under the GDPR: treat it as data to be shared carefully, not as data that has stopped being about people. Before anything is publicly archived it gets a proper disclosure review.

Delegates are never in it at all. Bracket does not record the name of an individual delegate anywhere: notes are about Parties, groups and roles, and a chair is a role and a Party ("Co-facilitator, Norway"). Free text is checked as it is written, your own downloads list anything that tripped the check so you can reword it, and the dataset export refuses to write a note that looks as though it names somebody unless the owner deliberately overrides it and the export says so. The check is a prompt and not a guarantee, which is the real reason the rule comes first.

What you can ask for

  • A copy of your own notes, at any time, from Review.
  • To see what an export would contain about you, before it is shared.
  • To have your notes left out of a specific publication or a specific release.
  • To stop taking part, without giving a reason and without it affecting anything else.

Write to contact@bracketresearch.org. Your rights under data protection law, which are stronger than this list in places, are in privacy-notice.md.