Where Does the Source Say That?

In the previous chapter we checked whether a document confirms a fact. But rules need grounds too. When someone receives a model, they may ask: where does the source say what appears here as a condition or a conclusion?

In Chapter 4 we already traced an explanation to a textbook fragment. Now we follow that path all the way to the saved text. We need to separate four things: the document itself, its edition, its publication, and the chosen place inside it. Then we can check the reference, discuss the rule’s meaning against the shared source, and ask how much of that source the rules cover.

From the rule to the words

Let us return to BCP 14 from Chapter 10. Here is the rule that links a requirement containing MUST to the specification’s absolute requirements:

@source(RFC2119_S1)
rule MustDenotesAnAbsoluteRequirement defeasible {
    label en official "MUST: this word means that the definition is an absolute requirement of the specification";
    for r: Requirement;
    when keyword_used(r, Must);
    then absolute_requirement(r);
}

The opening @source(RFC2119_S1) names the ground of the rule. It points to a declared fragment. It tells us which text to match the rule against; on its own it does not prove the match is correct[^chapter-12-source-model].

In sources.law, find that name:

fragment RFC2119_S1 in RFC2119_EN {
    kind section;
    locator "section/1";
    text en official """1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.""";
    content_hash "sha256:5cab6a6cdaacb5846bf7f4fe518a564097de37d01907ec17a13aa9b1b34e2dee";
}

fragment declares a fragment, RFC2119_S1 names it, and in RFC2119_EN ties it to one edition. Inside are the fragment’s kind section, the address section/1, and the exact English text in triple quotes. content_hash holds the checksum of that text.

In plain words: the word MUST, and also the terms REQUIRED and SHALL, mean that the definition states an absolute requirement of the specification. This paraphrase only aids reading; the English fragment stays the rule’s original ground.

Note a small difference in scope. The section names three equivalent words, while the rule above handles only Must. The package holds neighbouring rules for Required and Shall with the same reference. One fragment can ground several rules. A single reference does not mean that every part of the fragment has been expressed in a rule.

The document and its edition

The fragment has led us to RFC2119_EN. To see which text stands behind that name, read two linked declarations:

source RFC2119 {
    kind best_current_practice;
    jurisdiction IETF;
    authority IETF;
    number "RFC 2119, BCP 14";
    label en official "Key words for use in RFCs to Indicate Requirement Levels";
}

source presents the document as a work: here RFC 2119 with its number and title. kind states its type; jurisdiction and authority both name the IETF. This entry identifies the document, but it contains no file to read.

edition RFC2119_EN of RFC2119 {
    label en official "RFC 2119 (S. Bradner)";
    language en;
    officiality official;
    adopted @1997-03-01;
    in_force [@1997-03-01, infinity);
    materialization_status PINNED_OFFICIAL_BYTES;
}

edition identifies a particular version of the document in a given language. The of RFC2119 link states which document it belongs to. Here language en sets English, and officiality official marks official status.

The adopted and in_force fields hold the model’s dates. RFC 2119’s own header states March 1997, without a day. The first of the month is an explicit formalization convention here. That entry does not show that the source itself gives the date as 1 March exactly. The next chapter examines how dates affect the answer; for now note where the dates come from.

materialization_status PINNED_OFFICIAL_BYTES means the edition claims to keep the bytes of the official publication. This mark describes the origin of the pinned material. Check it against the publication and the file itself: the status name alone does not certify the source.

Where the text is

The concrete published form is set by publication:

publication RFC2119_EN_TEXT of RFC2119_EN {
    media_type "text/plain; charset=us-ascii";
    uri "https://www.rfc-editor.org/rfc/rfc2119.txt";
    retrieved_at @2026-08-30T09:00:00Z;
    content_hash "sha256:3c2ceb7bfc84cd34720f4a5271338ab9d8280d34bdd1eb250c64306202f2ed8b";
    local_path "sources/rfc2119/en.txt";
}

The of RFC2119_EN link points at the edition. media_type describes the file’s format, uri stores the publication’s address, retrieved_at the recorded moment of retrieval. local_path shows where the saved copy lies inside the package.

Different formats of the same content have separate publication records. The text file and the PDF can present the same edition yet differ byte for byte. Each file has its own checksum.

For our file, run from the reader companion directory:

python3 - <<'PYTHON'
from hashlib import sha256
from pathlib import Path
source = Path("corpus/laws/org/ietf/bcp14/sources/rfc2119/en.txt")
print(sha256(source.read_bytes()).hexdigest())
PYTHON

Compare the result with the publication’s content_hash, without the sha256: prefix. A match confirms that the file agrees with the stated fingerprint. It does not establish that the edition was chosen correctly or that its words were read correctly.

Do not confuse the two checksums in this chapter. The publication’s checksum covers the whole file, headers and layout included. The fragment’s checksum covers only the text between the triple quotes. They answer different questions, so they differ[^chapter-12-bytes].

What counts as a place in the text

Open the saved en.txt and find section 1. The RFC2119_S1 text should occur in it verbatim. The section/1 address names the place, and the matching words let us check the excerpt itself.

The fragment’s boundaries also need attention. In the RFC the document numbers the sections itself. In other materials we have already read, the division into fragments works differently:

The same word section in a locator does not turn an axiom into an RFC section. It is a convention for locating passages within the package. In Kafka the passage number likewise belongs to the model’s markup: the parable has no authorial section “erzaehlung/4”.

When handing over the model, explain both the unit’s name and how its boundaries were chosen. If a translation is used, name its language and edition. For example, the package’s Hilbert fragment points to E. J. Townsend’s English translation, while the Syzdyq fragment keeps the Kazakh text. The book’s English paraphrase helps read them but does not replace the pinned ground.

The BCP 14 package supplies a check that the excerpts agree with the saved publications:

python3 corpus/tools/sources/sync/sync_bcp14_fragments.py --check

It compares the declaration file against fragments extracted from the local texts. The check matters precisely because a mismatch is possible. A successful run reports that the checked files agree; whether the rule faithfully expresses the text is a separate judgment, still to be made against the source.

Two sources in one package

In BCP 14, RFC 8174 stands next to RFC 2119. Its header states Updates: 2119. It refines the use of the key words, while RFC 2119 stays a separate document. So the package has two sources, two English editions, and two text publications.

Section 2 of RFC 8174 quotes the old and the new text of RFC 2119’s paragraphs. The refinement: the special BCP 14 meanings belong to words in all caps. Lowercase forms keep their ordinary English meaning.

Consider the rule for the lowercase form:

@source(RFC8174_S2)
rule LowercaseKeywordCarriesNoDefinedMeaning defeasible {
    label en official "when these words are not capitalized, they have their normal English meanings and are not affected by this document";
    for r: Requirement; for k: Keyword;
    when keyword_written(r, k, Lowercase);
    then not keyword_used(r, k);
}

The reference now leads to RFC8174_S2 — a fragment of the other document. Within RFC 2119 alone, this rule has no ground.

Note precisely what the conclusion is about. The rule denies keyword_used: the word’s special BCP 14 meaning. It does not mark every lowercase must as optional; the word keeps its ordinary English meaning. RFC 8174 itself explains that normative text can do entirely without these key words.

A separate scenario 03 asks about the special meaning of the lowercase word and receives FALSE_ONLY:

law engine test \
  corpus/laws/org/ietf/bcp14/tests/03-lowercase-keyword-carries-no-force.lawtest \
  --program corpus/clir/ietf-bcp14.lawir.json --imports contexts/ietf-bcp14.json

The package also holds an explicitly selectable disputed reading, PreRfc8174Practice. Selecting it changes some answers. Chapter 14 examines that construction; here it is enough to separate the saved text from the rules that express one reading.

How much of the source the rules cover

Now we can ask about coverage. First, define what we count: the numbered sections of each RFC. RFC 2119 has nine, RFC 8174 five. Headers, annotations, and page layout fall outside this count. Still, RFC 2119’s annotation is kept as a separate fragment, because RFC 8174 updates its text.

A section-by-section check gives this picture[^chapter-12-coverage]. EXECUTABLE marks sections with rules in the base model, INTERPRETED those with rules only in the selected reading, and SOURCE_ONLY those kept as text without concluding rules:

For RFC 2119 the first group’s share is 6 of 9, about 66.7%. For RFC 8174 it is 2 of 5, or 40%. These are shares of numbered sections linked to the base model’s rules. They do not measure how much meaning was read correctly, nor how completely each section was analysed.

Here are the remaining sections. RFC 2119’s section 7 covers security matters; its rules apply only under a separate reading. Sections 8 and 9 hold acknowledgements and the author’s address. In RFC 8174, sections 3 and 4 report that no IANA actions are required and there are no related security matters, and section 5 holds the normative reference. These parts are kept and named, so that the boundary of the formalization is stated rather than left silent.

A coverage percentage does not replace this list. Even a section in the EXECUTABLE group may state a condition the rule misses. And a missing rule for acknowledgements has a different reason than a missing rule for a substantive requirement. To judge coverage, look at both sides: which provisions appear, and what stayed outside the boundary.

Try walking the route yourself

1. Find MustNotDenotesAnAbsoluteProhibition. From its @source go to the fragment, then find the same words in the saved publication. Explain the text’s meaning and how the rule records it, each separately.
2. Copy RFC 2119’s en.txt into a temporary file. In section 1 replace absolute requirement with optional requirement. Compare the checksums of the original and the copy. Will the unchanged RFC2119_S1 text still occur in the altered file?
3. Match RFC 2119’s sections 7–9 against the coverage table. How does selecting a reading differ from keeping a section without rules? Why is one number not enough?
4. Take a short text from the prologue. Name the document itself, the specific edition, and the available publication. Choose one fragment. Mark which boundaries and dates come from the source and which you propose for the model.

We have traced the path from the rule back to the words that both sides of a discussion can read. One question still needs to be made precise: as of which date does this text ground the answer? The next chapter starts there.

[^chapter-12-source-model]: The Arxo specification, §§27–28: document, edition, publication, and fragment. The BCP 14 declarations live in sources.law; the @source reference names the ground for matching against the rule. [^chapter-12-bytes]: The pinned RFC 2119 publication and the official text. The sync_bcp14_fragments.py script with the --check flag compares the declarations against the local publications’ fragments without writing. [^chapter-12-coverage]: The unit of counting is the numbered section. The reasons for keeping without rules are listed in the accounts of RFC 2119 and RFC 8174. The classification by links with rules is computed by check_formalization_depth.py; a share of sections does not measure the completeness of their meaning.