Some questions here will only be answerable against real data. How a library of a
hundred thousand items behaves, how a real account set looks after a migration, what
a real log actually contains. Refusing those questions outright would make the board
less useful than it should be, and pretending they will not come up guarantees the
first one is handled badly.
Set the rule for them now.
An experiment that touches real personal data declares it in its record, before it
starts, in the same commit that writes the question. The declaration says what
category of data, on whose host, and what will be written down about it.
The data never enters the tree. Not as a fixture, not as a sample, not as an
attachment, not redacted, and not in a screenshot. Redaction is specifically named
because it is the failure mode that feels safe: a partially masked identifier is
still an identifier, and a screenshot of a list is a copy of the list.
What may be written down is the measurement. A distribution, a timing, a count, a
shape. Anything that describes the data without carrying it.
The experiment says what it did with the data when it stopped. An experiment that
left a copy somewhere and does not say so is not finished.
Where synthetic data can answer the question, it does, and the record says why real
data was needed when it was. That sentence exists to make the easy path the default
without banning the hard one.
This adds a second field to a format the runner already reads, and it takes the same
route as the first. The record that fixed the format is not edited; a later record
names it and says what was added and why. Two issues in this plan grow that format
after it is fixed, and if either one edits it in place the decision directory stops
being a history of what was argued and becomes a description of what is currently
there, which any reader could get from the template instead.
Done when the rule is written in docs/privacy.md, the record format carries the
declaration field, a superseding decision record names the record it supersedes and
gives the reason for the field, and the runner refuses a record whose declaration is
present but says nothing about what was written down.
Some questions here will only be answerable against real data. How a library of a
hundred thousand items behaves, how a real account set looks after a migration, what
a real log actually contains. Refusing those questions outright would make the board
less useful than it should be, and pretending they will not come up guarantees the
first one is handled badly.
Set the rule for them now.
An experiment that touches real personal data declares it in its record, before it
starts, in the same commit that writes the question. The declaration says what
category of data, on whose host, and what will be written down about it.
The data never enters the tree. Not as a fixture, not as a sample, not as an
attachment, not redacted, and not in a screenshot. Redaction is specifically named
because it is the failure mode that feels safe: a partially masked identifier is
still an identifier, and a screenshot of a list is a copy of the list.
What may be written down is the measurement. A distribution, a timing, a count, a
shape. Anything that describes the data without carrying it.
The experiment says what it did with the data when it stopped. An experiment that
left a copy somewhere and does not say so is not finished.
Where synthetic data can answer the question, it does, and the record says why real
data was needed when it was. That sentence exists to make the easy path the default
without banning the hard one.
This adds a second field to a format the runner already reads, and it takes the same
route as the first. The record that fixed the format is not edited; a later record
names it and says what was added and why. Two issues in this plan grow that format
after it is fixed, and if either one edits it in place the decision directory stops
being a history of what was argued and becomes a description of what is currently
there, which any reader could get from the template instead.
Done when the rule is written in
docs/privacy.md, the record format carries thedeclaration field, a superseding decision record names the record it supersedes and
gives the reason for the field, and the runner refuses a record whose declaration is
present but says nothing about what was written down.