Equivo

Equivo is a short course in reading explicit models: a token and its claim, evidence for and against that claim, a finite graph, and a finite record of accumulating designations. Seven rooms contain thirty checks. The checker computes a reading of the supplied model; it cannot establish whether a real bridge is safe, a witness is reliable, or an organization is aligned.

The stages

1. Articulate: keep the token and what it says distinct.

2. Relate: make a subject/predicate/object cell. Here the token is both subject and object, and the claim is its predicate.

3. Measure: read the two evidence sides as [for, against]. The four names are this software's presentation vocabulary.

4. Settle a graph: count its connected components and independent cycles.

5. Observe a stage record: predict the software's regime label and the number of new designations at marked limit stages.

These readings concern different carriers. A graph cycle is not automatically a contradiction, and a component is not proof that its members are identical. The marked-stage exercise is a finite model; its labels do not demonstrate an actual infinite process.

The three populated presentation lenses change vocabulary while keeping the computation fixed. The Lakotaean lens remains visibly absent pending owner-authored material; the course supplies no invented Lakota mathematical terms. Complete a lesson's checks to open the next. Export your save to retain progress outside this browser. The lesson notes below also work without JavaScript.

Sources and scope

FOUR has distinct truth and knowledge orders; see Arieli and Avron, Reasoning with Logical Bilattices, §2. For graph cohomology, see Hatcher, Algebraic Topology, §3.1, Example 3.5. The marked-stage vocabulary is the repository's metrologic/obstruction/settling model, rather than an identification of arbitrary temporal data with topological cohomology.

The evidence wording was corrected on 2026-10-04: the second bit records evidence against, not confirmation. Existing exercise identifiers and saves remain usable; revisit Measuring Charge if you learned the earlier wording.

The descent's first move is the smallest one: take a raw scenario and pull two things out of it without deciding anything else yet. Something is there — a token, a mark, a thing pointed at. Something is said about it — a claim, a predicate-in-waiting. Keeping those two apart, cleanly, is what articulate does.

articulate([token, claim])  →  { potential: [token, claim] }

It is deliberately not doing anything clever. It witnesses the pair — that's the whole operation. The reason this deserves its own stage, rather than being folded into "relating" (next lesson), is that conflating a token with the claim made about it is the single most common way an equivalence judgment goes wrong later on: you cannot ask "are these the same?" honestly until you know which part of what you're looking at is the thing, and which part is the assertion about the thing.

A scenario: a 3-3 stone is played directly in a corner. The token is the stone itself — a concrete move, on the board, right now. The claim is what that move asserts: a corner invasion, territory not yet settled. Distinguish them, and you can go on to ask whether the claim is warranted. Conflate them, and every later question about whether the position "is" a corner invasion becomes unanswerable, because you never separated the move from the assertion in the first place.

Every exercise below runs the real articulate function on the scenario's utterance and checks your answer against what it actually returns — not against a pre-written key.

Notice the pattern: in every case, articulate hands back exactly the pair you gave it, in order — it never reorders, never infers which side is "really" the subject. That's intentional. Deciding which atom plays which role in a relation is the next stage's job, not this one's. Getting this stage right is entirely about resisting the urge to skip ahead — do not try to judge whether the claim is true yet. That question doesn't even make sense until Relating Cells gives the claim somewhere to land.

One preview, before you move on — the next stage in one bite, so you've already seen its shape before the next lesson names it formally:

Now that a scenario is distinguished into a token and a claim, the second stage gives that pair somewhere to live: a cell. A cell is a subject/predicate/object triple — the shape every relation in this course is ultimately built from. predicate reads the potential you articulated and produces the cell-set Φ = E × Π × E: an entity set (drawn from the token) and a predicate set (drawn from the claim).

predicate({ potential: [token, claim] })
  →  { "cell-set": { entity-set: { entities: [token] }, predicate-set: { predicates: [claim] } }, ... }

For a single bare utterance, this produces exactly one entity and one predicate — the token becomes the entity set's sole member, the claim becomes the predicate set's sole member. That's not a simplification for teaching purposes; it's what the real function does with a single scenario. Richer relations (several entities, several claims tying them together) are what the next lesson starts to measure, and what Settling Equivalence reads whole graphs of.

Continuing the corner-invasion scenario: the 3-3 stone (token) and the corner-invasion claim distinguished last lesson relate into a cell whose entity set is ["3-3 stone"] and whose predicate set is ["corner-invasion"]. Nothing has been measured yet — you don't yet know whether the claim holds. You've only given it a structural home to be measured in.

A useful check on your own understanding, not graded here: notice that predicate never evaluates whether the claim is warranted — it only builds the structure a later stage will measure. A cell can hold a claim that turns out false just as readily as one that turns out true; relating is purely about shape, not verdict. The verdict is next.

A quick review before you go on — the stage before this one, on a fresh scenario, to keep it warm:

A related cell carries evidence on two independent sides: evidence for its claim and evidence against it. Read whether each side is nonempty. The answer is [for, against].

The names come from the software's knowledge reading; they are not ordinary-language judgments. In particular, stable here names conflicting evidence on both sides, not verified truth. The standard logical names for the same points are neither, true, false, and both. Truth and knowledge are orders on the four points, not the two checkbox coordinates.

Each exercise constructs one reflexive cell with one supplied witness for the claim and no witness against it. No inference or transport rule adds evidence, so its fixed point is already [true, false]. A second supporting witness would still leave the same two-bit reading: the bits record presence, not confidence or a witness count. Independent confirmation is not the second bit.

A bridge-safety assertion in an exercise is only an assertion in this model. Measuring its evidence sides does not inspect a bridge or establish that assertion's truth. Predict the carrier the exercise actually supplies.

A relation is a finite list of subject/predicate/object cells. For this exercise, each subject and object is a vertex, and each cell is an oriented edge. Predicate labels remain in the supplied cells but do not affect the connectivity calculation. The orientation chooses the sign of an incidence row; connected components are read from the underlying undirected graph.

The graph has the cochain complex C⁰ = ℤ^vertices → C¹ = ℤ^edges, with no higher cells. A vertex function is a zero-cocycle precisely when its values agree across each edge. Such functions are constant on each connected component, giving one independent integer choice per component. Thus the rank of H⁰ counts components.

The checker uses “equivalent” as a short label for one connected component. This is the equivalence relation generated by allowing paths in either direction. It does not prove that two people, objects, or propositions are the same, or that their assertions agree.

For this graph, the rank of H¹ is edges − vertices + components, the number of independent cycles. A spanning forest uses vertices − components edges; each remaining edge closes an independent cycle. A cycle can be useful redundancy. Its presence alone supplies no verdict about truth, contradiction, or whether a repair is wanted.

A chain A → B → C has three vertices, two edges, and one component: ranks (H⁰, H¹) = (1, 0). Two disjoint pairs have ranks (2, 0). A triangle has (1, 1): connected and cyclic at the same time. These distinctions are what the exercises ask you to read.

This lesson changes carriers. It supplies a finite, marked stage record, not the graph from Settling Equivalence. Each stage contains a cumulative set of designated cells. Designations cannot disappear. A limit marker is supplied as data; the browser does not run an infinite ordinal sequence to discover it.

For each stage, subtract all previously designated cells to find the new ones. The model counts new cells at marked limit stages and names that count its H¹ rank. This is the repository's defined marked-stage reading; the course establishes no equivalence between it and the graph cohomology of the previous lesson.

Predict the model's labels

• strict: the record contains no marked limit stage.

• scott: there are marked limit stages, but none introduces a new cell.

• transfinite-bounded: at least one new cell appears at a marked limit stage, without the uncountable-cofinal declaration.

• aperiodic: such a firing is present and the input also declares cofinal: "uncountable".

The first two cases have rank zero; the last two have positive rank. Two new cells at the same marked limit stage contribute two to the count. The software's depth is its bounded reading of the last firing and the supplied markers.

A finite record and a declaration do not prove uncountable cofinality, nonstabilization, mathematical Scott continuity, or physical aperiodicity. These exercise answers name cases of this particular classifier. Use the names with their carrier attached, and require additional evidence before applying them to an actual process.

Choose the carrier before calculating its reading:

• A token and claim ask you to distinguish or relate them.

• One witness for a reflexive claim supplies evidence sides [true, false].

• A finite edge list asks for connectivity. The checker calls one component “equivalent”; independent cycles are a separate reading.

• A cumulative stage record asks for the marked-stage model's label and whether its limit-firing count is zero.

A chain on four vertices has one component and no independent cycles. Two disjoint triangles have two components and two independent cycles. Neither result, by itself, judges the truth of a claim attached to those vertices.

For the stage record, visiting a marked limit stage without adding a cell contributes nothing to the limit-firing count. If a later marked limit stage introduces a cell, the count becomes positive. With no uncountable-cofinal declaration, the model labels that case transfinite-bounded. This is a computation on the supplied record, not evidence that an infinite process occurred.

The useful skill is to keep these distinctions when moving between examples. The two readings called H¹ belong to different supplied models; a common name does not make their carriers interchangeable. Completing this unit demonstrates practice with the thirty checks. It is not a certification of mathematical mastery or of real-world alignment.