SpecSheriff
rule · _guidelines/spec/5.1 · s-jau82aq9juv9zzh

What is checked, when, and what a failure costs

Checkedconfirmed by its owner

Two things are checked mechanically: that the specification holds together on its own, and that the specification and the code still describe each other. Every check is deterministic but one: whether the code does what the nodes it names say, and nothing they do not, is judged at every commit that changes code by an independent reviewer (§s-nyh9yk22ba6g77q). The checks run when a commit is made, and the tests of the system's code before a commit is shared; each check reads the commit being made, and the history behind it where its row says so, never what the commit does not hold. A check refuses unless its row says otherwise.

The specification on its own

What is checked On failure
No file of the specification, of its archive or of its schema gives one field two values refused
Every file matches its schema refused
No two nodes share a sid refused
No two nodes share an id refused
Every node's id is the address its place gives refused
Every term node stands in contracts refused
No two term nodes name the same term, whatever the case of its letters refused
No two data record nodes share a name, whatever the case of its letters refused
A node outside the SpecSheriff guidelines a project takes is checked only where a confirmation holds the fingerprint of its wording and names the node's owner refused
A node a commit removes, outside the SpecSheriff guidelines a project takes, is deleted where no confirmation of it was ever given, and otherwise stands in the archive with the reason for its removal refused
Every link names a node refused
A node citing another holds a link to it, and a link of type cites stands only where its node cites the node it names and holds no link of another type to it refused
No node cites another by its address refused
A term-relation or a uses link binds two terms, and no other type of link, cites included, binds two terms refused, and settled with the specification's owner
The incoming links are what the outgoing ones produce refused
No checked node sets three words or more running in capitals outside a name quoted from the code refused
A checked section holds at least one rule refused
Every domain has a header, and the index in it is what the domain's sections produce refused
Every domain's header names a level the project's own guidelines list refused
A consumes link goes from a domain's header to a section of another domain refused
An exempts link goes from a node of the project's own guidelines to a rule or a section refused
The domains do not use one another in a cycle refused
A data record variant refines the data record it is a variant of refused
A data record variant stands in the part of the specification that declares the value it answers to refused
A data record variant declares at least one field held neither by its data record nor by any field of type variant of that data record refused
A data record variant answers to values of exactly the fields its data record names as choosing the variant, each value declared in its choosing field's own list of values or in a list a domain defines for that field refused
No two variants of one data record answer to the same values refused
Each value of a field choosing a data record variant is declared once refused
A list declaring values of a field choosing a data record variant stands in a rule of a domain, which refines a data record described in contracts naming that field as choosing its variant refused
A data record holds at most one field of type variant, the ones it inherits counted refused
Every field of type one of holds at least one value, in its own list or in a list a domain defines for it refused
A field of type identifier of names a data record that names the field identifying it, one of its fields, and the identifying fields it leads to, followed from one identifier to the next, end in a field of another type refused
Every node of the technical appendix but a section, outside the sections of the stack and of the technical debt, implements a node of the base specification, and every rule of the technical debt refines one refused
Every section of the technical appendix but those of the stack and of the technical debt stands under the name of a domain refused
Every rule of the appendix of the tools (§s-a4rbry4hsu34hy8) implements a node of the base of the guidelines refused
Every rule of a project's own guidelines refines or implements a rule of the SpecSheriff guidelines refused
No project but the one the SpecSheriff guidelines are written in holds a copy of them or of their schema refused

The specification and the code

What is checked On failure
Every symbol of the system's code carries a tag naming the node it implements, or, where it implements none of the system's logic, the tag that says so and gives its reason refused
Every tag names a node that exists, and a tag on a symbol whose code a commit changes a checked one refused
Every tag stands on the symbol it binds refused
Every test of the system's code carries the sid of a rule or a term that exists, and a test a commit adds or changes the sid of a checked one refused
Every rule whose code a commit adds or changes has a test carrying its sid refused
A node's lists of code and tests are what the tags and the sids the tests carry produce refused
A node that names the symbols in a file is held to them refused
A list a node carries matches the declaration in the code or in the schema it names refused
No file the repository keeps outside the specification and its tools names a node by its address refused
A citation in the code, the tests and the documents names a node by its sid refused
Every copy generated from the nodes and kept in the repository, such as the types and runtime checks of the system's code, is exactly what the nodes produce now, or, while it waits for a node not yet checked, left unchanged by the commit: neither edited by hand nor left behind nodes that are all checked refused
A copy of the system's code that waits for a node not yet checked reported by the node's sid
A rule whose text has changed since its code last changed, as the history of the repository shows reported by the node's sid
A checked rule outside the SpecSheriff guidelines, the project's own guidelines and the technical debt has a symbol carrying its tag and a test carrying its sid, its own or those of a rule implementing it, or is exempted reported by the node's sid
A commit that changes code names every checked node its changed symbols' tags name, and no header or section refused
The code does what the nodes it names say, and nothing they do not refused, naming the node and the line
The tests of the system's code pass the commit is not shared
Why

A person asking whether a commit will go through must find the whole answer in one place: spread across several rules, the answer comes apart, and one rule ends up contradicting another without anybody seeing it.

Every check but the review is binary, so refusing costs nobody a judgement, and a check that sometimes refuses for a reason nobody can reproduce is bypassed at the first chance and never trusted again. The review is the one judgement, because whether code does only what its rules say cannot be decided by a script.

A check reads the commit being made, because a judgement of anything else would pass or refuse what is not being committed. The tests run before a commit is shared rather than when it is made, since a suite takes longer than a commit should wait, and a commit not yet shared misleads nobody.

The check of drift only reports, because a rule outrunning its code is drift worth knowing about and not the fault of whoever's commit found it. A checked rule not implemented is reported rather than refused, since a rule is checked before its test and its code are written (§s-rah8b37kytb682y).

The links it makes

The links made to it

The decisions taken on it

2026-10-07 · textual
Problem

No check held the code to what its rules say: that was left to a review run on purpose, and none was run, so logic no rule stated reached a domain beside code that cited two checked rules.

Ruling

The owner: every change to the code meets every requirement of the specification, checked at every commit by a separate, independent reviewer and by scripts that refuse logic with no reference back to the specification.

2026-10-07 · textual
Problem

The row refused a test opening with a term's sid, which §s-rah8b37kytb682y now admits, and read a test as changed where a deleted neighbour lent it the diff's lines.

Ruling

The owner: a changed test opens with the sid of a checked rule or term, and a test is changed when its text is.

2026-10-07 · textual
Problem

The data record nodes, and the code generated from them, had no check.

Ruling

The owner: the checks of the specification hold a variant of a data record to its data record and its values to the fields that choose the variant; the binding holds the generated code to what the data record nodes produce.

2026-10-25 · textual
Problem

The checks of a data record's forms let a form hold nothing and read the values choosing a form off the forms alone.

Ruling

The owner: a data record variant declares a field of its own and answers to a value declared once.

2026-10-25 · textual
Problem

The check of the appendix's implements links would have refused every rule of the technical debt, which falls short of the nodes it concerns rather than carrying them out, and debt named the binding's report of a rule outrunning its code as well.

Ruling

Carried from the owner's ruling of the same day on the technical debt (§s-2r7k2aeyusgy6fw): the debt's rules are held to a refines link to a node of the base and its section to none, and the binding's report is named the drift, the word this rule's reason already used, so that debt names one thing.

2026-10-27 · textual
Problem

The table named the commands and the hooks of one toolset, and held rows only one project's specification needed.

Ruling

The owner: the base keeps what is checked and what a failure costs; how, and by which command, is described in the appendix of the tools (§s-a4rbry4hsu34hy8), and a project's own rows stand in its own guidelines.

2026-10-30 · textual
Problem

Read row by row, the table left checks unclear or unmade: a term could stand in a domain with nothing refusing it, names differing only in case passed as two terms or two data records, two abbreviations side by side were refused as stress, one row joined five checks of a data record variant, and several rows named a thing without its object or read as cut off.

Ruling

The owner: a term stands only in contracts; terms and data records are named once whatever the case of their letters; capitals are refused from three words running; the checks of a data record variant stand one to a row; and the rows on the appendix of the tools, the tags, addresses, generated copies and drift say what they check in full.

2026-10-31 · textual
Problem

A field of type one of could hold no value at all, and identifiers could lead from one identifying field to the next back to a data record already passed; neither has a type the implementation can be given, and nothing refused them.

Ruling

Carrying out the owner's rulings of that day on where the values of a field of type one of are declared and on the type of an identifier: both are refused.

2026-10-31 · textual
Problem

The row let a test carry the sid of any node that exists.

Ruling

Following the owner's ruling on §s-rah8b37kytb682y: a test carries the sid of a rule or a term.

2026-10-31 · textual
Problem

Nothing reported a checked rule that the system's code did not carry out, and no row held where an exempts link may stand.

Ruling

Following the owner's rulings on §s-6fw72j65jkqrfpf and §s-sn6au3vcr9uy5pm: a checked rule neither implemented nor exempted is reported and refuses nothing; an exempts link goes from a node of the project's own guidelines to a rule or a section.

2026-10-31 · textual
Problem

The row held every node of the technical appendix to implement a node of the base, its sections included, and no row held a section of the appendix to the name of a domain.

Ruling

Following §s-vj7ercem526zd6v: a section of the technical appendix implements nothing and stands under the name of a domain.

2026-10-31 · textual
Problem

The row held every kept generated copy to what the nodes produce now, while code generated from the nodes now waits for them to be checked.

Ruling

Following the owner's ruling on §s-kh8qcd5kxgh9z3j: code generated from the nodes waits until every node it is generated from is checked, no commit changing it meanwhile, and its lag is reported.

The tests bound to it