How a change is accepted

The governing rule is that accepted registry records and generated views are not hand-edited. The repository does hold older records made before the present gate, and one lossless split migration that the owner authorised; what follows is the supported route for new and corrected accepted knowledge. It has four steps. First the change is drafted as a proposal, setting out exactly what it would add or alter and what it rests on. Then it is previewed, laid out in full for the owner to read before anything is committed. Next it is accepted, as a deliberate act, or it is not. Only then is it applied and written into the record itself. The public views a reader sees are rebuilt from the record afterwards, as a separate step.

A rule about who may act sits behind those four steps. Only one controlled path may write accepted knowledge, and everything else stays firmly on the near side of it. The tools that go out to the archives to fetch a scan or run a search can prepare material and set it down as a draft, but they cannot change the record themselves. If one tries, the attempt fails outright instead of half-writing. Only the intake coordinator drives accepted changes through that path.

The gate sorts faults into two kinds. Some stop a change outright. A reference may lead nowhere, to a document never registered. A change may file the same scan under two records, or carry a reference that does not line up with what it names. An accepted decision may have gone stale because the proposal checksum or the project revision changed. Or a rule protecting a living person may be broken, for instance by a contact for a living person that is not marked public, or that cites no source. Other faults are flagged, not blocked: a source whose file is not preserved, with no recorded reason for the gap, is marked, so the missing document shows up as missing and is never passed off as present. In both cases the fault shows up before the change settles.

What the gate checks is narrower than truth. It checks that an accepted change hangs together: its references resolve, its evidence bindings are registered, and any required evidence bytes, or an allowed reason for having none, are accounted for. Other missing-file conditions may stay visible as validation warnings. The gate does not judge history, and it does not guarantee that a claim is correct. The record can hold two accounts that disagree, and a well-formed change can still be a wrong reading. That is why the site also keeps an open account of the values it has since had to correct.