One Word, Several Definitions

In the previous chapter the kilogram’s definition changed with the date. But different definitions can also coexist. Then the date alone no longer tells us which meaning we intend.

Return to chemistry. In Part I we recorded that a particle donates or accepts a proton. Now ask whether it counts as an acid. Finding the definition in the textbook seems enough. Yet Chemistry 2e presents several definitions, and each requires different information.

This table retells the model’s conditions briefly. The textbook explains them through the behaviour of reaction participants; a donor, for example, passes a proton to another particle. We still do not derive that behaviour from the chemical formula. The case states it as information[^chapter-14-definitions].

So make the question “is it an acid?” precise: under which definition? In Arxo the chosen definition becomes an explicit part of the context, stored alongside the answer.

First give the definitions different names

The familiar vocabulary lives in the openstax.chemistry_acids package. The chem.acid_base package builds its acid and base definitions on it. Here is one of those rules:

@source(openstax.chemistry_acids::OS_14_1_BRONSTED)
pub rule BronstedAcidDonatesProton strict {
    label ru unofficial "отдающая протон частица — кислота Брёнстеда—Лоури";
    label en unofficial "a compound that donates a proton is a Brønsted-Lowry acid";
    for s: openstax.chemistry_acids::Species;
    when openstax.chemistry_acids::donates_proton(s);
    then bronsted_acid(s);
}

After when comes the familiar donates_proton relation; after then, the new bronsted_acid. Once the particle’s proton donation is established, the rule derives bronsted_acid for that particle.

The long name openstax.chemistry_acids::donates_proton says which package the relation comes from. The double colon separates the package name from the declaration name. Chapter 16 explains dependencies; for now recognize the old vocabulary behind this entry. The @source reference leads to the pinned fragment of the textbook’s section 14.1.

The model holds three separate relations: arrhenius_acid, bronsted_acid, and lewis_acid. Ask about each by name. Explicit links may also connect them: a separate rule, for example, concludes bronsted_acid from arrhenius_acid. The fact that these names all end in _acid creates no such link by itself.

The general question is is_acid. Its English label reads: “the species is an acid under the selected reading”. A reading supplies the link from this general question to one specific definition.

How to declare a reading

A reading is a named way of understanding the source, expressed through the model’s rules. Here it states which definition answers the general acid question.

Below is the start of the BronstedReading declaration and its first inner rule. The other three rules are omitted: BaseIsBronstedBase links the base definition to the general base question; NotAcidUnderBronsted and NotBaseUnderBronsted provide the negative links. All appear in the package’s 02-readings.law file.

pub interpretation BronstedReading of openstax.chemistry_acids::OS_14_1_BRONSTED {
    status authoritative;
    label ru unofficial "прочтение Брёнстеда—Лоури: кислота — донор протона";
    label en unofficial "Brønsted-Lowry reading: an acid is a proton donor";
    source_anchor openstax.chemistry_acids::OS_14_1_BRONSTED;

    @source(openstax.chemistry_acids::OS_14_1_BRONSTED)
    rule AcidIsBronstedAcid strict {
        label ru unofficial "по прочтению Брёнстеда кислота — кислота Брёнстеда";
        label en unofficial "under the Brønsted-Lowry reading, an acid is a Brønsted-Lowry acid";
        for s: openstax.chemistry_acids::Species;
        when bronsted_acid(s);
        then is_acid(s);
    }

    // Three more rules are omitted from this excerpt.
}

The word interpretation introduces the reading, BronstedReading names it, and of points at the fragment it construes. The source_anchor field records the same source link inside the declaration body. Both identify the text being interpreted; neither selects the reading or supplies the inner rule’s premise. That rule says: once bronsted_acid is established, conclude is_acid.

This rule joins the derivation only when BronstedReading is selected. The BronstedAcidDonatesProton definition above stands outside the reading. It can conclude bronsted_acid whatever is selected. The selection matters for the step to the general is_acid question.

The status authoritative line records the model’s appraisal of the reading. It does not prove the formalization correct, nor does it select the reading on its own. Here all three readings carry that mark, yet a choice is still required.

The readings are gathered into a group for that choice:

interpretation_group AcidDefinition {
    alternatives ArrheniusReading, BronstedReading, LewisReading;
    selection exactly_one;
}

alternatives lists the options, and selection exactly_one requires exactly one. This is the package’s condition for answering the general question. It does not claim the definitions exclude each other in chemistry: one particle may satisfy several of them. To compare them, ask the same question several times, selecting a different reading each time[^chapter-14-selection].

Follow the information to the answer

Take the package’s complete check example. The case reports that the hydrogen-chloride particle under study donates a proton. The reading is selected inside context:

language "law.core" version "0.2";
package chem.acid_base version "0.1.0";
namespace "urn:chem:clir:acid-base";

test "urn:query:chem-acid-base-02-hcl-bronsted" {
    given {
        context {
            decision_time @2026-09-06T12:00:00Z;
            knowledge_time @2026-09-06T12:00:00Z;
            legal_time @2026-09-06;
            timezone "UTC";
            interpretation BronstedReading;
        }
        assert openstax.chemistry_acids::species_in_question(entity_ref("urn:case:chem:hcl")) { id "ab02-q"; origin case_input; }
        assert openstax.chemistry_acids::donates_proton(entity_ref("urn:case:chem:hcl")) { id "ab02-1"; origin case_input; }
    }
    evaluate truth(is_acid(entity_ref("urn:case:chem:hcl")));
    expect truth_status == TRUE_ONLY;
    expect evaluation_status == COMPUTED;
    expect applied(BronstedAcidDonatesProton);
    expect interpretations(BronstedReading);
}

The interpretation BronstedReading; line fixes the question’s meaning. species_in_question presents the object under study, and donates_proton reports its property. The is_acid conclusion itself is not among the starting assertions.

The result is the following chain — a simplified diagram, not a literal printout of the explanation:

donates_proton(hcl)                         starting information
  → bronsted_acid(hcl)                      definition rule
    → is_acid(hcl)                         reading rule

In the explanation the last rule is named BronstedReading/AcidIsBronstedAcid. That name shows which reading linked the definition to the answer.

The first expectation checks TRUE_ONLY, the second the COMPUTED status. The next two check the definition rule’s application and the selected reading’s role. The passing test confirms these expectations on the stated information. The report of the particle’s behaviour stays a case condition: the test does not turn it into a chemistry experiment’s result.

If no reading is selected

The changes below can first be followed as thought experiments. To run them, use the temporary-copy setup under “Try changing the question” at the end of the chapter.

Delete one line from the example’s copy:

interpretation BronstedReading;

Leave the dates, assertions, and question as they are. For is_acid we get truth_status = NEITHER and evaluation_status = INTERPRETATION_REQUIRED. The conclusion is not established, and the status names exactly what is missing: the selection of a reading.

Contrast this with a case where a reading is selected but the information it needs is missing. Select ArrheniusReading in the same case, keeping the proton-donation report. That report does not establish that the particle dissolves in water and releases hydrogen cations. The answer is NEITHER with COMPUTED status: the question has a definite meaning, but the needed premises are not established.

In the unselected case why-not lists the unselected readings. The missing selection blocks an answer to the general is_acid question; the original proton-donation information remains in the case.

Same information, different definitions

Now change the example. In the boron-trifluoride case record that the particle accepts an electron pair and does not donate a proton. Below are all three starting assertions of scenario 10, inside given after the context:

assert openstax.chemistry_acids::species_in_question(entity_ref("urn:case:chem:bf3")) { id "ab10-q"; origin case_input; }
assert openstax.chemistry_acids::accepts_electron_pair(entity_ref("urn:case:chem:bf3")) { id "ab10-1"; origin case_input; }
assert not openstax.chemistry_acids::donates_proton(entity_ref("urn:case:chem:bf3")) { id "ab10-2"; origin case_input; }

Leave these entries and the dates unchanged. Change only the reading-selection line. For the same is_acid question we get:

In all three cases the calculation status is COMPUTED. The answers differ because the selected definitions set different conditions. Do not merge the positive Lewis answer and the negative Brønsted answer into BOTH: they come from different contexts.

The negation in the second case needs explanation. The model holds a separate rule:

@source(openstax.chemistry_acids::OS_14_1_BRONSTED)
pub rule NotBronstedAcidWithoutDonation strict {
    label ru unofficial "предъявленная частица с опровергнутой донорностью протона — не кислота Брёнстеда";
    label en unofficial "a presented species whose proton donation is refuted is not a Brønsted-Lowry acid";
    for s: openstax.chemistry_acids::Species;
    when openstax.chemistry_acids::species_in_question(s)
        and refuted(openstax.chemistry_acids::donates_proton(s));
    then not bronsted_acid(s);
}

The familiar refuted requires an established negation: FALSE_ONLY on the premise. Together with species_in_question it concludes not bronsted_acid. Then the selected reading’s NotAcidUnderBronsted rule uses that refutation, together with species_in_question, to conclude not is_acid. If the case simply omits whether the particle donates a proton, this chain does not fire.

The textbook cites boron trifluoride as a Lewis-acid example. But our table checks what follows from the case’s specific entries. In particular, missing information about water is a gap in this case. It does not prove the substance never interacts with water or was never studied.

Contradictory information under a single reading

Keep BronstedReading and consider a hypothetical particle x. Now the case holds two opposite entries:

assert openstax.chemistry_acids::donates_proton(entity_ref("urn:case:chem:x")) { id "ab17-yes"; origin case_input; }
assert not openstax.chemistry_acids::donates_proton(entity_ref("urn:case:chem:x")) { id "ab17-no"; origin case_input; }

They concern one object in one context. Unlike the previous table, here the starting assertions diverge, not the definitions.

Check each link separately:

All three queries carry COMPUTED status. The positive rule needs TRUE_ONLY on donates_proton; the negative one needs FALSE_ONLY. Under BOTH neither condition holds. This case has no other grounds for acidity, so the conflict does not carry through to the conclusion[^chapter-14-conflict].

That is how these rules behave. It does not mean every contradiction under a reading yields NEITHER. Check the state on each claim: on our original premise it is exactly BOTH. And selecting another definition does not delete the contradictory entries from the case, though it may make them irrelevant to the new question.

When a reading is tied to a disagreement about the text

In the chemistry example, different definitions from one textbook stand side by side. In BCP 14 from Chapter 12, the situation differs: the model checks a disputed reading of the document’s words.

The base rules see no special BCP 14 key-word meaning in a lowercase must. The PreRfc8174Practice reading admits one. Its rule adds a premise for that conclusion, and the package’s separate priority lets it defeat the opposing rule in the base model.

With the same information about a lowercase must and the same dates, keyword_used receives FALSE_ONLY in the base model and TRUE_ONLY with the reading selected. Here PreRfc8174Practice carries status disputed. Selecting it explores that position’s consequences; it does not prove that the position is historically correct.

No group here demands that reading’s selection. Its absence therefore keeps the base answer rather than giving INTERPRETATION_REQUIRED as in the acid example. Also, keyword_used asks strictly about the key word’s special meaning. A negative answer does not strip the sentence of all normative sense.

The name PreRfc8174Practice does not move the case into the past either. The date stays a date, and a separate line selects the reading. Changing one field never substitutes for the other.

Try changing the question

The companion includes the acid-definitions package with its pinned chemical vocabulary. Make a working copy from reader/:

mkdir acid-study
cp -R corpus/laws/doctrine/chem/acid-base/. acid-study

Run its checks:

law test acid-study

The seventeen scenarios should pass. The command builds the package with its received dependency; Chapter 16 explains how that pinning is checked.

For each exercise, edit acid-study/tests/chem-acid-base.lawtest and run law test acid-study again. Predict the result before changing expectations, and begin each exercise with an unchanged copy of the scenario file.

1. In scenario 02 replace BronstedReading with ArrheniusReading. What information would be needed for a positive answer? Check NEITHER, COMPUTED, and the new reading; drop the old definition rule’s application expectation.
2. In scenario 10 delete the negative proton-donation assertion. Why should the old FALSE_ONLY change to NEITHER? Drop the negative rule’s application expectation, keeping the selected reading and COMPUTED.
3. In a separate copy of the same scenario name a hypothetical particle exercise-x, select LewisReading, and leave only the object’s presentation and the explicit denial of electron-pair acceptance. Check FALSE_ONLY and COMPUTED. Which negative rule must now be seen in the explanation? Do not carry this exercise’s condition over to boron trifluoride’s real properties.

When someone else hands you an answer, ask not only about the date and the source but also about the selected definition. If the answers diverge, compare these grounds first. The next chapter adds one more refinement: the units a number is written in, and what survives conversion.

[^chapter-14-definitions]: Chemistry 2e: §14.1 — Arrhenius and Brønsted–Lowry, §15.2 — Lewis. The package’s rules apply to reported properties; the chemical formula itself does not produce these premises. [^chapter-14-selection]: The Arxo specification, §§152–156: readings, statuses, groups, and selection. The AcidDefinition group and its alternatives are set in 02-readings.law; the mandatory selection concerns the group-dependent question. [^chapter-14-conflict]: Scenario 17 states opposite information about donorship. The BronstedAcidDonatesProton and NotBronstedAcidWithoutDonation rules in 01-definitions.law call for TRUE_ONLY and FALSE_ONLY respectively; under BOTH both chains in this case are stopped.