# Governance

Everything below is generated from `CONTRIBUTING.md` in
[the repository](https://github.com/touchstone-standard/touchstone). It is the
same text a contributor meets when they open a pull request, and it is not
maintained separately here — a governance page that can quietly drift from the
document it describes is worse than no governance page at all.

A company stewarding an open standard it wrote is the normal starting point,
not an anomaly. Most standards worth adopting began this way and moved to a
foundation later, once enough people depended on them that neutral governance
was worth the overhead. That is the path we expect to follow, and a foundation
ratifies adoption rather than creating it, so it is not a step we can usefully
take today.

Touchstone is stewarded by Grailology, LLC, and it has one maintainer today.
That maintainer decides every proposal alone, and works for a company that
builds commercial products on Touchstone and is entering the card grading and
authentication market. That makes the steward a direct competitor of many of
the labs and tools most likely to adopt Touchstone. That is a real conflict of
interest, not a disclosure formality. Weigh it before you build on this. It is
here because a standard whose steward hides its position in the market is not
worth adopting.

Proposals are decided by the Chair, in the pull request, in writing, with
reasons stated. When the project has three or more maintainers, decisions move
to maintainer consensus, with the Chair holding a tie-break and a veto that
must be publicly justified.

There is one maintainer because the project is new and nobody has asked to be
another. That is the reason, not a preference. We want more, and we want them
from outside Grailology most of all, because a standard maintained only by the
company that sells against it is worth less to everyone including us. The path
is the ordinary one: contribute, keep contributing, and say you want it. There
is no committee to get past.

We won't invite lightly. A maintainer's judgement decides what every
implementation of this standard has to do, and a grade computed under it is
someone's money. So the bar is sustained work rather than one good pull
request, and we would rather leave a seat empty than fill it to look open.
If you're serious, so are we.

Until then, be clear about where that leaves you. Maintainers are appointed by
the Chair. There is no independence requirement. That three-maintainer
threshold counts maintainers, not independent ones, so reaching it does not by
itself put anyone from outside Grailology in the room. Once there is more than
one, each maintainer is listed with their affiliation, so you can check that
rather than infer it from a count.

We intend to rotate the Chair rather than hold it indefinitely. We are not
putting a date on that, because a rotation among one person is theatre and the
prerequisite is a standard enough people rely on that the seat is worth having.
That is the work. Help us do it.

This document is amended by the process it describes, with one exception. The
licensing commitment above may be broadened but never narrowed, and this
process cannot reach it.

## Proposing a change

Typos, a broken link, tooling, a number the vectors already contradict. Just
open a pull request.

Anything that changes what a conforming implementation must do goes through a
**TIP**, a Touchstone Improvement Proposal:

1. Open a pull request that adds one file to `proposals/`.
2. Once the pull request has a number, rename the file to match it:
   `proposals/0042-binding-region-tiebreak.md`.
3. Write these five sections, in this order:
   - **Motivation** - what is wrong today, with a card that shows it.
   - **Specification** - the normative change, precise enough to implement
     from without reading the discussion.
   - **Rationale and Alternatives** - why this shape, and what you rejected.
   - **Backward Compatibility** - which previously valid inputs score
     differently, and what implementers have to do about it.
   - **Reference Implementation** - the change to `scoring.mjs` and the rubric
     data.

No proposal reaches final without both a reference implementation and a
conformance vector: at least one vector that tells the new behaviour apart from
the old. Agreement in the thread is not the bar. Running code and a vector that
pins it are.

## Sign off on your commits

Every commit needs a `Signed-off-by:` line. Git will add one for you:

```
git commit -s -m "your message"
```

If you forget, `git commit --amend -s` and force-push the branch. Commits
without a sign-off can't be merged.

The sign-off is the [Developer Certificate of
Origin](https://developercertificate.org/), version 1.1: a short statement that
you wrote the change, or otherwise have the right to submit it under this
project's licence. Not a copyright assignment, not a CLA. You keep your
copyright.

We use a DCO rather than a contributor licence agreement on purpose. It buys
you three things. We acquire no rights in your contribution that you and every
third party do not equally hold. Nothing we have already published can be taken
back. Any fork starts on exactly the footing we stand on.

It does not, by itself, guarantee that this project's licence can never change.
We are not going to claim that it does. What is promised, and what binds, is in
the licensing commitment below.