Affirm

An affirmation is an authoritative source saying, at a time, that a value has not changed.

It has an author, a time, and an outcome — it can be refused — and it produces information without changing anything. That combination is what makes it an act rather than a read, and giving it a place in the log is what lets the system distinguish nobody has looked at this since Tuesday from someone checked it this morning and it was right.

The trouble that produced this cut was a single word carrying two mechanisms.

The re-stamp is a new row copying the previous envelope verbatim: no author’s claim, no outcome of its own. It is a system version, below the model’s resolution, and it is excluded from the occurrence read. It keeps the name touch.

The affirmation is the act above. It gets its own name, Affirm, because naming it after the mechanism is what caused the confusion in the first place. Two things sharing one name is the defect; giving the act its own name is the fix, and the alternative buys nothing but the word.

The spine needed no change to accommodate it. The chaining law holds, because an affirmation’s post is its pre. The record read is unchanged across it. And the spine’s own read is already named for exactly this: the latest committed occurrence at or before a time. After an affirmation, that read returns the affirmation and the record is the same one it was.

The claim names a version, and that is the point

An affirmation carries affirmed: one Rec — the specific version the source is claiming is still current.

Without it the act is a blind ping. “I checked and it is so” and “I checked and it is not” are different facts, and only the first is an affirmation. A physical count that agrees with the system is an affirmation whose claim is the current record; a count that disagrees is not an affirmation at all, but the module’s own adjusting act. The binding is what separates them, and a check that cannot express the second is not checking.

Three refusals follow, and the pattern for which vocabulary owns each is the spine’s usual one — the adopter names the refusal where it has a domain reading, the family names it where it does not:

Condition	Refusal
the subject was never created	the adopter’s own not-created atom
the subject is retired	the adopter’s own retired atom
the claim names a version that is not the current one	`RStaleAffirmation`, declared once in the affirm module

The third is the family’s because staleness has no domain reading: it means the caller’s information is old, in every log, for the same reason.

What it is for

The record read is last observation carried forward. Between occurrences, the system assumes the value persists — a reasonable assumption, and an assumption nonetheless. An affirmation turns the carried-forward value into an evidenced one at a point in time.

That makes the age of a value’s last evidence a readable quantity: the time of the latest committed occurrence on the subject. Confidence in a count becomes a function of that age, an affirmation resets it without touching the count, and none of it requires a new read — the spine already has the one it needs, as soon as affirmations are occurrences on the log.

The first adopter for that reading is the inventory pool, whose counts are the ones that go stale in a way anybody notices.

Effective time, and the one case deferred

On the domain logs an affirmation takes its own tick. Where “at a particular point in time” has to mean a domain instant rather than a causal position, the affirm kind is the natural first adopter of the timed occurrence, with clocks assumed aligned in the first version — that is, no backdated affirmations.

Backdating is deferred deliberately. An affirmation dated before its own recording claims evidence about a past version, which needs a two-clock read that does not exist yet. Allowing it before that read exists would let the log carry a claim nothing can check.

Sources

The affirm module is meta/subject_log/affirm.als, adopted by each log that offers the act rather than declared inside the spine — the opt-in shape, so that a log does not carry a kind its domain does not offer. Cut at commit 3b2ad797 on branch jmpicnic/domain-ontology-affirm-kind of Saldubatech/manufacturing-ontologies; the retired arm was added with the lifecycle family at 793cfe0.

The argument, the four senses of the word, and the decision to name the act rather than the mechanism are from notebooks/domain-ontology/streams/samwise/touch-as-affirmation-act.md. Its §8 and §9 are the operator’s own text, checked claim by claim before adoption; two of its earlier claims were corrected in that checking and the corrections are in §10 — including one that assumed the affirm path shared the ordering guard of an ordinary update, which the runtime read showed it does not.

The staleness reading is the deferred half. It has a design topic of its own and is not part of this cut.