Participant disclosure

This site is published by the sgit project, about the role definitions the same project's own product team wrote for itself, and it argues that those definitions are worth using as a reference. That is not a neutral vantage point, and a site is better off saying so on the way in than being caught at it later.

Who publishes this

The conflict, stated plainly

A project publishing a reference site about its own team's internal practice is doing something with an obvious pull to it: it is grading its own homework, and every incentive points toward finding the practice more coherent than it is. There is no external team here whose role definitions were rejected for the comparison — the roster is drawn entirely from one estate.

Three things are done about that, and none of them make it go away:

• Every count is computed, not asserted. The roster data drives every number on this site, and validate.js recomputes them independently on every release. A number that flatters the estate and a number that is simply wrong look the same to a hand-typed count; they do not look the same to a script that reads the same file twice.
• The gaps are published as gaps. Six of nineteen roles have no ROLE.md at all, and the format's best property — the falsifiable claim — regressed in a later migration that nobody flagged until this pack measured it. Both are on the front page, not buried in a footnote.
• The open questions stay open, in public. Seven questions this site cannot answer are addressed to the founder and left unresolved rather than quietly assumed one way.

How this site is written

By an AI agent, from a commissioning brief, with a human lead reviewing and directing. What that means for a reader: the prose was drafted by a model, the structure and the argument were directed by a person, and everything either of them produced had to pass a release gate that does not care who wrote it. The gate checks what is checkable — links, versions, canonical URLs, quotation attribution, roster arithmetic, credential shapes. It cannot check whether a role's claim is actually true of the team that wrote it. That part rests on the same source-verification discipline the whole pack runs on: never publish a role definition, or a number about one, that does not exist on disk.

Where this approach is weakest

Here are three places the honest version of this page names.

1. The corpus is one estate, once. Nineteen roles, four team instantiations, one company. The "portable core" finding — six roles independently reached for twice — is the closest thing to a controlled experiment the corpus contains, and it is still an n of two, inside one organisation. A reader generalising from this site to their own team is extrapolating from a sample size the site cannot enlarge.

2. Effectiveness is asserted, not measured. Eighteen role files carry a ## Measuring Effectiveness section; no measurement appears anywhere in the corpus. This site can show these roles are defined, used and revised. It cannot show they work better than an alternative, because nothing in the source material measures that either — G5.

3. This page is written by the party it discloses. The disclosure above is drafted by the same agent, for the same project, under the same incentives it describes. It is not an audit. What it can do is state the objections precisely enough that someone who does not share the incentive can check them — which is the same defence the rest of the site runs on, and no stronger here than anywhere else.