7.3. The seal of the computation — the tape
A carrier-generic module has a second record of its computation, one that no harvest
produces. The tape is automatic differentiation's word for the
record of the operations a program performs, in the order it performs them. TorchLean's
autograd tape is that record as data: a grow-only array of nodes, each one operation with
the ids of its parents in operand order, its forward value and its local backward rule, and
every operation appends exactly one node. The name comes from reverse-mode differentiation,
which replays the record backward to accumulate gradients; the calculus never runs that
pass. It reads the tape forward — the code generator lowers it, and the evaluator the cone
lemma below is about re-computes every node from an environment of leaf values. A tape is
therefore a straight-line program, not a graph. A module writes one when instantiated at
the recording carrier — the carrier whose values are
not numbers but thunks that append their sub-expression to the tape and return the result
node. Because the branchless carrier class carries no ordering to Bool, a module written
against it cannot branch on its data, so one recording covers every input.
The computational tape graph is the directed acyclic graph the record determines: one vertex per tape node, an edge from each parent to its node, the in-edges of a vertex ordered as its parents are — acyclic because every parent precedes its node in the array. Its leaves are of exactly two sorts, a named input and a baked constant; its roots are the recorded outputs; and it carries no kinds, since a value of any kind records the same node. The name pairs it with the metrological provenance hypergraph: one is what the source declares about kinds, the other is what the code computes, and the second capstone is the relation between them. Graph or hypergraph? A tape node is its operation, so a vertex's ordered in-edges are the one hyperedge into it, and reading the tape as an ordered hypergraph adds nothing to the graph. The provenance hypergraph is a hypergraph in a stronger sense: its occurrences are objects apart from its nodes, and several occurrences may derive one node. The compacted tape — the tape after its identical sub-expressions are merged, so that its graph is the graph of the distinct sub-expressions rather than of their unfolding — is the very object the code generator lowers to a kernel.
The recording carrier, as a structure: one deferred build action that, run inside the tape monad, appends this sub-expression's nodes and yields its result node. Every branchless-carrier operation is realized as one appended node, so instantiating a module at this carrier builds its tape, with one leaf per named input and one per host constant.
Lean code for Definition7.3.1●1 definition
Associated Lean declarations
-
structuredefined in PropertyKindCalculus/Torch/Paradigm/TapeCarrier.leancomplete
structure PropertyKindCalculus.Paradigm.TapeBuilder (s : Spec.Shape) : Type
structure PropertyKindCalculus.Paradigm.TapeBuilder (s : Spec.Shape) : Type
**The tape carrier.** A `TapeBuilder s` is a deferred tensor sub-program over the pixel batch shape `s`: running it inside `TapeM` appends its nodes to the autograd `Tape` and returns the id of its result tensor. The underlying tensor carrier is `Float` (the executable tape). A WO1 kernel instantiated at `α := TapeBuilder s` *is* the batched kernel.
Fields
run : Runtime.Autograd.TapeM Float ℕ
The deferred build action: emit this sub-expression's nodes, yield its result id.
Each arithmetic operation runs its operands and emits one node. Sharing is not recorded — a sub-expression named twice emits twice — and the compaction that merges identical sub-expressions is a separate pass over the recorded tape.
The denotation bridge: a recording-carrier value evaluates to a tensor when, on any tape, running it succeeds, its result node carries that tensor, and the run only extends the tape. Each carrier operation preserves the bridge with its matching elementwise operation, proved once per operation, so a module's parity with its own eager value at the same source is the mechanical chaining of those lemmas — and needs no numerical side condition, both carriers using the same clamped operations.
Lean code for Definition7.3.2●1 definition
Associated Lean declarations
-
defdefined in PropertyKindCalculus/Torch/Paradigm/TapeParity.leancomplete
def PropertyKindCalculus.Paradigm.TapeParity.Evaluates {s : Spec.Shape} (b : PropertyKindCalculus.Paradigm.TapeBuilder s) (v : TorchLean.Tensor Float s) : Prop
def PropertyKindCalculus.Paradigm.TapeParity.Evaluates {s : Spec.Shape} (b : PropertyKindCalculus.Paradigm.TapeBuilder s) (v : TorchLean.Tensor Float s) : Prop
**The carrier-to-tensor bridge.** On any tape, running `b` succeeds with a node carrying `v`, the node id is in range, and the run only extends the tape.
A four-conjunct predicate; the per-operation preservation lemmas are proved from the tape's forward-value faithfulness lemmas through a run bridge, and a composite kernel's parity is a chain of them.
Evaluation reads only the cone. Re-evaluating a tape from an environment of leaf values gives, at every node, a value that depends only on the leaves in that node's backward cone in the tape graph: two environments agreeing on the cone's named leaves give the same value at the node. The tape-side counterpart of the pedigree reading.
Lean code for Theorem7.3.3●1 theorem
Associated Lean declarations
-
theoremdefined in PropertyKindCalculus/Torch/Paradigm/TapeSeal.leancomplete
theorem PropertyKindCalculus.Paradigm.TapeSeal.evalTape_cone (t : Runtime.Autograd.Tape Float) (hwf : PropertyKindCalculus.Paradigm.TapeCodegen.WF t) {env₁ env₂ : String → Float} {vals₁ vals₂ : Array Float} (h₁ : PropertyKindCalculus.Paradigm.TapeCodegen.evalTape env₁ t = Except.ok vals₁) (h₂ : PropertyKindCalculus.Paradigm.TapeCodegen.evalTape env₂ t = Except.ok vals₂) (v : ℕ) (hagree : ∀ (u : ℕ), PropertyKindCalculus.Paradigm.TapeSeal.Reaches (PropertyKindCalculus.Paradigm.TapeCodegen.ofTape t) u v → ∀ (n : Runtime.Autograd.Node Float), t.getNode? u = some n → n.parents.isEmpty = true → ∀ (nm : String), n.name = some nm → env₁ nm = env₂ nm) : vals₁.getD v 0.0 = vals₂.getD v 0.0
theorem PropertyKindCalculus.Paradigm.TapeSeal.evalTape_cone (t : Runtime.Autograd.Tape Float) (hwf : PropertyKindCalculus.Paradigm.TapeCodegen.WF t) {env₁ env₂ : String → Float} {vals₁ vals₂ : Array Float} (h₁ : PropertyKindCalculus.Paradigm.TapeCodegen.evalTape env₁ t = Except.ok vals₁) (h₂ : PropertyKindCalculus.Paradigm.TapeCodegen.evalTape env₂ t = Except.ok vals₂) (v : ℕ) (hagree : ∀ (u : ℕ), PropertyKindCalculus.Paradigm.TapeSeal.Reaches (PropertyKindCalculus.Paradigm.TapeCodegen.ofTape t) u v → ∀ (n : Runtime.Autograd.Node Float), t.getNode? u = some n → n.parents.isEmpty = true → ∀ (nm : String), n.name = some nm → env₁ nm = env₂ nm) : vals₁.getD v 0.0 = vals₂.getD v 0.0
**Evaluation reads only the cone.** On a well-formed tape, two environments that agree on every named leaf in the backward cone of a vertex give the same value at that vertex.
Strong induction over the vertex id, through the node-value characterisation of the
evaluator's fold (evalTape_node_value): a leaf reads its own name or constant, and an
operation applies its scalar to values already established for its parents, each earlier
in the tape and each in the cone.
The kind-transporting weak bisimulation.
The relation that ties the two graphs of one module together: the provenance hypergraph
g, harvested from the source, where every kind originates, and the computational tape
graph of the tape T the same module records, which carries none. R relates nodes of g
to vertices of the tape graph. It is total on the observable vertices — leaves, roots, and the operands and
results of every matched occurrence — and silent on the interior vertices a single kinded
operation expands to at the carrier: the real projections of a complex product, the
sub-graph of a principal square root, the plumbing an operation registered as carrier
vocabulary performs. That silence is what makes it weak: an interior vertex is a step
neither side observes. It simulates in both directions, which is what makes it a
bisimulation. Hypergraph to tape: every occurrence of g is matched to a tape sub-graph
whose frontier is the images of the occurrence's operands and whose operations realize the
occurrence's family, per a realization table with one entry per family and carrier. Tape to
hypergraph: every path of the tape graph between observable vertices projects along R to
a path of g — the direction the seal consumes. R matches leaves to sources, ports by
name and constants by value. A step edge to a member whose audit tier licenses a
re-typing is realized by a wire, and it is the only place the kinds transported along R
may change across a tape edge. The coarsest reading R preserves is the boundary's
propagation relation — which source ports reach
which produced ports through the occurrences — and comparing that relation, rather than
occurrence lists, is what makes the match robust to sharing. R is not a bijection, for
four reasons present in the code: compaction merges tape nodes many-to-one; one kinded
operation is several carrier operations; two uses of one witness are two occurrences by
design; and a nominal selection is resolved at recording time into one tape per branch.
The relation is a weak bisimulation in the textbook sense — Sangiorgi's, through cslib's
labelled transition systems — between two systems over one label alphabet: a visible step
is an edge family with the operand position it enters at, and the silent step is the wiring
the harvest records as copy, a procedure edge, and every carrier-level interior step. The
provenance layer's transitions are the hops of its occurrences; the tape graph's are its
edges, labelled through the match. As data the relation is a match: a component table —
each node of g with the tape vertices realizing it, one for a real carrier, two for a
complex one — and one realization per occurrence, the interior vertices of its sub-graph.
The observable relation is node to component; the interior of a realization is related to
the occurrence's result, the result under construction. Acceptance is a decidable judgment
on the match, each clause of which some proof below consumes.
Lean code for Definition7.3.4●1 definition
Associated Lean declarations
-
PropertyKindCalculus.Paradigm.Match.weak[complete]
-
PropertyKindCalculus.Paradigm.Match.weak[complete]
-
defdefined in PropertyKindCalculus/Graph/Bisimulation.leancomplete
def PropertyKindCalculus.Paradigm.Match.weak {ν κ : Type} [BEq ν] (g : PropertyKindCalculus.Provenance ν κ) (m : PropertyKindCalculus.Paradigm.Match ν) : ν → ℕ → Prop
def PropertyKindCalculus.Paradigm.Match.weak {ν κ : Type} [BEq ν] (g : PropertyKindCalculus.Provenance ν κ) (m : PropertyKindCalculus.Paradigm.Match ν) : ν → ℕ → Prop
**The kind-transporting weak bisimulation**: the observable relation composed with the contraction — a node to each of its components, and the result of a realized occurrence to each interior vertex of the realization.
Decided, never assumed: acceptance is a Boolean over the match, decided by evaluation in a probe and by kernel reduction in a theorem. A matcher that finds the match from the leaves of a recorded tape — ports by name, constants by recording site, each occurrence by a realization table per family and carrier — is the instrument the ledger prices, and the refactoring it needs stands: the recorder must name its constant leaves, and either mark the scope of each member call on the tape or the matcher must widen the member set to the closure the tape sees through.
The accepted match is a weak bisimulation. When acceptance holds for R between a
well-formed g and T, the bisimulation is a weak
bisimulation, in both directions: every hop of g from a node is matched, from each of the
node's components, by a tape step with the same label up to silent steps, and every tape
step from a vertex is matched from every node the vertex is related to. The direction the
seal consumes follows as a corollary: every path of the tape graph from a component of a
node s to a component of a node b projects along R to a path of the value-flow
digraph from s to b (reachable_of_tape_path_comps); and every tape edge between two
observable vertices realizes one hop of one occurrence of g, with the kinds that
occurrence names for its operand and its result (occurrence_of_edge) — so the kinds
transported along R change across a tape edge only where an occurrence of g states the
change. The tape-side analogue of the lemma that makes the influence probe's false a
theorem — so an accepted match is evidence rather than a report.
Lean code for Theorem7.3.5●1 theorem
Associated Lean declarations
-
theoremdefined in PropertyKindCalculus/Graph/Bisimulation.leancomplete
theorem PropertyKindCalculus.Paradigm.Match.isWeakBisimulation_weak {ν κ : Type} [BEq ν] [LawfulBEq ν] [BEq κ] {g : PropertyKindCalculus.Provenance ν κ} {T : PropertyKindCalculus.Paradigm.TapeGraph} {m : PropertyKindCalculus.Paradigm.Match ν} (hwf : g.WellFormed) (hA : PropertyKindCalculus.Paradigm.Match.Acc g T m) : g.lts.IsWeakBisimulation (PropertyKindCalculus.Paradigm.Match.tapeLts g T m) (PropertyKindCalculus.Paradigm.Match.weak g m)
theorem PropertyKindCalculus.Paradigm.Match.isWeakBisimulation_weak {ν κ : Type} [BEq ν] [LawfulBEq ν] [BEq κ] {g : PropertyKindCalculus.Provenance ν κ} {T : PropertyKindCalculus.Paradigm.TapeGraph} {m : PropertyKindCalculus.Paradigm.Match ν} (hwf : g.WellFormed) (hA : PropertyKindCalculus.Paradigm.Match.Acc g T m) : g.lts.IsWeakBisimulation (PropertyKindCalculus.Paradigm.Match.tapeLts g T m) (PropertyKindCalculus.Paradigm.Match.weak g m)
**The kind-transporting weak bisimulation.** Under well-formedness and acceptance, the composite of "node to its components" with the contraction is a weak bisimulation between the provenance layer and the tape graph: the weak bisimulation factors as the strong one with the contracted graph composed with the contraction.
By factoring rather than by induction over an acceptance derivation: the strong
bisimulation with the contracted tape graph composed with the contraction
(the contraction lemma), cslib's composition of weak
bisimulations. The projection is the tape-to-hypergraph half of the saturated bisimulation,
iterated along the path, with the observable vertices at both ends read back to their
nodes through injectivity of the component table; the kind clause is covering and
closedness of the sub-graphs read at one edge, with occurrencesTyped for the kinds.
The contracted tape graph. Let acceptance hold
for R between g and T, so that each occurrence o of g has a realizing sub-graph
S_o of the tape graph: its interior, its roots — the components of the result — and its
frontier, the components of the operands in operand order. The contraction collapses each
S_o to one ordered hyperedge from the frontier to the roots, labelled by the occurrence's
family and the operand position; a wire is a silent step. It is defined — an ordered
hypergraph of the same signature as g, with no interior — under the clauses acceptance
decides of the sub-graphs: closed, every parent of a sub-graph vertex is an interior or a
frontier vertex, so no value enters except through the operands; interior-private, every
edge leaving an interior vertex stays inside S_o, so no interior value is read from
outside; progressing, every interior vertex feeds the sub-graph, so it lies on a path to
a root; used, every frontier vertex feeds the sub-graph; disjoint, the interiors of
distinct sub-graphs do not overlap and no interior vertex is a component; and covering,
every operation vertex of the tape graph lies in some S_o. Leaves are matched by
recording site, not by value, so that two constants of one value stay two leaves.
Lean code for Definition7.3.6●1 definition
Associated Lean declarations
-
defdefined in PropertyKindCalculus/Graph/Bisimulation.leancomplete
def PropertyKindCalculus.Paradigm.Match.contracted {ν κ : Type} [BEq ν] (g : PropertyKindCalculus.Provenance ν κ) (m : PropertyKindCalculus.Paradigm.Match ν) : Cslib.LTS ℕ PropertyKindCalculus.Paradigm.KindLabel
def PropertyKindCalculus.Paradigm.Match.contracted {ν κ : Type} [BEq ν] (g : PropertyKindCalculus.Provenance ν κ) (m : PropertyKindCalculus.Paradigm.Match ν) : Cslib.LTS ℕ PropertyKindCalculus.Paradigm.KindLabel
**The contracted tape graph**: one hyperedge per realized occurrence, from a component of the operand at a position to a component of the result, labelled by the family and the position; a wire is a τ step. No interior.
One hyperedge per accepted occurrence, between components; the clauses are Boolean conjuncts of acceptance, and a sub-graph violating one is a match acceptance refuses. The recorder's obligation is the named constant leaf, the same one the bisimulation's definition already prices.
Contraction makes the bisimulation strong. Under acceptance and well-formedness, R
restricted to the observable vertices — node to component — is a strong bisimulation
between g and the contracted tape graph: every hop of g
is matched by one hyperedge of the contraction and conversely, with no silent step, and
once the two node-identity mismatches are quotiented away it is an isomorphism of ordered
hypergraphs — compaction, by matching against a hypergraph quotiented by derivation
equality; nominal selection, by matching per branch. The contraction itself — a component
to every component of its node, a root to every interior vertex of its realization — is a
weak bisimulation between the contracted and the actual tape graph
(isSWBisimulation_contraction), and the weak bisimulation
between g and the tape graph is their composite: the weak bisimulation factors as this
strong one composed with the contraction, which is the standard relation between weak and
strong bisimulation up to silent-step abstraction. What the strong form deliberately loses
is the interior, and the interior is where the numerical side conditions live: the license
clause and the adequacy layer keep working on the uncontracted tape graph.
Lean code for Theorem7.3.7●1 theorem
Associated Lean declarations
-
theoremdefined in PropertyKindCalculus/Graph/Bisimulation.leancomplete
theorem PropertyKindCalculus.Paradigm.Match.isBisimulation_contracted {ν κ : Type} [BEq ν] [LawfulBEq ν] [BEq κ] {g : PropertyKindCalculus.Provenance ν κ} {T : PropertyKindCalculus.Paradigm.TapeGraph} {m : PropertyKindCalculus.Paradigm.Match ν} (hwf : g.WellFormed) (hA : PropertyKindCalculus.Paradigm.Match.Acc g T m) : g.lts.IsBisimulation (PropertyKindCalculus.Paradigm.Match.contracted g m) m.obs
theorem PropertyKindCalculus.Paradigm.Match.isBisimulation_contracted {ν κ : Type} [BEq ν] [LawfulBEq ν] [BEq κ] {g : PropertyKindCalculus.Provenance ν κ} {T : PropertyKindCalculus.Paradigm.TapeGraph} {m : PropertyKindCalculus.Paradigm.Match ν} (hwf : g.WellFormed) (hA : PropertyKindCalculus.Paradigm.Match.Acc g T m) : g.lts.IsBisimulation (PropertyKindCalculus.Paradigm.Match.contracted g m) m.obs
**The contraction lemma.** Under acceptance, "node to its components" is a strong bisimulation between the provenance layer and the contracted tape graph: every hop of the hypergraph is matched by one hyperedge of the contraction and conversely, with no silent step.
The strong half is a corollary of acceptance alone — totality and injectivity of the component table, one realization per occurrence, and well-formedness for the result of every occurrence to be a declared node. The contraction's half is where the sub-graph clauses work: an interior vertex reaches a root through silent steps (progress, with the tape's order for termination), a frontier vertex enters the sub-graph (used), and a step from an interior vertex stays inside it (interior-private), while an interior vertex is related to nothing observable (disjointness). No new instrument: acceptance already decides every clause.
The seal of the computation. Let f be a
module written once against the branchless carrier class with fixed-extent iteration, g
its provenance hypergraph with c its declared boundary, and T the well-formed tape f
records. Suppose (H1) g is well-formed, so that the seal of the
module holds of it and, under agreement, of c; (H2) acceptance holds for a match R
between g and the computational tape graph of T; and (H3) at a carrier, the value of
f at an output o evaluates to the re-evaluation of T at
the vertex realizing o. Then for every node o — in particular every produced port —
and every vertex r realizing it: two environments that agree on the leaves realizing the
influencers of o — the sources g names for it — give the same value at r, hence the
same value of f at that carrier (semantic_seal_of_denotes); every leaf in the cone of
r, a named input or a baked constant, realizes an influencer of o — every constant the
computation uses is one the assumption ledger lists; and every tape edge between observable
vertices realizes one hop of one occurrence of g, with the kinds that occurrence names —
every kind change in the computation sits under an occurrence the source states. The
hypergraph's absence claims become semantic: an input the harvest says cannot reach o
provably does not, in the computation, at every carrier the bridge reaches.
Lean code for Theorem7.3.8●1 theorem
Associated Lean declarations
-
theoremdefined in PropertyKindCalculus/Torch/Paradigm/TapeSeal.leancomplete
theorem PropertyKindCalculus.Paradigm.TapeSeal.semantic_seal {ν κ : Type} [BEq ν] [LawfulBEq ν] [BEq κ] {g : PropertyKindCalculus.Provenance ν κ} (hwf : g.WellFormed) (t : Runtime.Autograd.Tape Float) (hwft : PropertyKindCalculus.Paradigm.TapeCodegen.WF t) {m : PropertyKindCalculus.Paradigm.Match ν} (hacc : PropertyKindCalculus.Paradigm.Match.accepts g (PropertyKindCalculus.Paradigm.TapeCodegen.ofTape t) m = true) {o : ν} {r : ℕ} (hr : r ∈ m.comps o) : (∀ (env₁ env₂ : String → Float) (vals₁ vals₂ : Array Float), (∀ s ∈ g.influencers o, ∀ u ∈ m.comps s, ∀ (nm : String), (PropertyKindCalculus.Paradigm.TapeCodegen.ofTape t).name? u = some nm → env₁ nm = env₂ nm) → PropertyKindCalculus.Paradigm.TapeCodegen.evalTape env₁ t = Except.ok vals₁ → PropertyKindCalculus.Paradigm.TapeCodegen.evalTape env₂ t = Except.ok vals₂ → vals₁.getD r 0.0 = vals₂.getD r 0.0) ∧ (∀ (u : ℕ), PropertyKindCalculus.Paradigm.TapeSeal.Reaches (PropertyKindCalculus.Paradigm.TapeCodegen.ofTape t) u r → (PropertyKindCalculus.Paradigm.TapeCodegen.ofTape t).isLeaf u = true → ∃ s ∈ g.influencers o, u ∈ m.comps s) ∧ ∀ (u w : ℕ), (PropertyKindCalculus.Paradigm.TapeCodegen.ofTape t).edge u w = true → ∀ (a b : ν), u ∈ m.comps a → w ∈ m.comps b → ∃ oc ∈ g.occurrences, oc.result = b ∧ ∃ i k, oc.operands[i]? = some (a, k) ∧ (g.kindOf? a == some k) = true ∧ (g.kindOf? b == some oc.resultKind) = true
theorem PropertyKindCalculus.Paradigm.TapeSeal.semantic_seal {ν κ : Type} [BEq ν] [LawfulBEq ν] [BEq κ] {g : PropertyKindCalculus.Provenance ν κ} (hwf : g.WellFormed) (t : Runtime.Autograd.Tape Float) (hwft : PropertyKindCalculus.Paradigm.TapeCodegen.WF t) {m : PropertyKindCalculus.Paradigm.Match ν} (hacc : PropertyKindCalculus.Paradigm.Match.accepts g (PropertyKindCalculus.Paradigm.TapeCodegen.ofTape t) m = true) {o : ν} {r : ℕ} (hr : r ∈ m.comps o) : (∀ (env₁ env₂ : String → Float) (vals₁ vals₂ : Array Float), (∀ s ∈ g.influencers o, ∀ u ∈ m.comps s, ∀ (nm : String), (PropertyKindCalculus.Paradigm.TapeCodegen.ofTape t).name? u = some nm → env₁ nm = env₂ nm) → PropertyKindCalculus.Paradigm.TapeCodegen.evalTape env₁ t = Except.ok vals₁ → PropertyKindCalculus.Paradigm.TapeCodegen.evalTape env₂ t = Except.ok vals₂ → vals₁.getD r 0.0 = vals₂.getD r 0.0) ∧ (∀ (u : ℕ), PropertyKindCalculus.Paradigm.TapeSeal.Reaches (PropertyKindCalculus.Paradigm.TapeCodegen.ofTape t) u r → (PropertyKindCalculus.Paradigm.TapeCodegen.ofTape t).isLeaf u = true → ∃ s ∈ g.influencers o, u ∈ m.comps s) ∧ ∀ (u w : ℕ), (PropertyKindCalculus.Paradigm.TapeCodegen.ofTape t).edge u w = true → ∀ (a b : ν), u ∈ m.comps a → w ∈ m.comps b → ∃ oc ∈ g.occurrences, oc.result = b ∧ ∃ i k, oc.operands[i]? = some (a, k) ∧ (g.kindOf? a == some k) = true ∧ (g.kindOf? b == some oc.resultKind) = true
**The seal of the computation** (the second capstone). Let `g` be a well-formed provenance hypergraph, `t` a well-formed tape, and `m` a match between `g` and the graph of `t` that the matcher accepts — the kind-transporting weak bisimulation. Then at every node `o` of `g` and every tape vertex `r` realizing it: two environments that agree on the leaves realizing the influencers of `o` give the same value at `r`; every leaf in the cone of `r` — a named input or a baked constant — realizes an influencer of `o`; and every tape edge between observable vertices realizes one hop of one occurrence of `g`, with the kinds the occurrence names.
By (H3) the value of o at the carrier is the tape's value at r; by
the cone lemma that value depends only on the named leaves in
the cone of r; by the accepted match each such leaf
is a component of a source whose tape path to r projects to a path of the value-flow
digraph to o, so the source is an influencer of o — the assumption ledger (H1) prints.
The kind clause is the accepted match's edge reading.
Non-vacuity of the seal of the computation. (i) An instance in which acceptance is
decided by the kernel and the recorded tape is the accepted graph: the module
y = a · b + e at the complex carrier over the recording carrier, whose hypergraph has a
product and a same-kind sum and whose tape expands the product to (ac − bd) + (ad + bc)j
— four interior vertices the bisimulation is silent on. Acceptance is closed by decide;
the strong bisimulation, the contraction, the weak bisimulation, the cone lemma and the seal
of the computation are instantiated on it; and the tape the recorder writes, compacted,
projects vertex for vertex onto that graph — a runtime check, since the tape's stored
tensors are opaque to the kernel — with the recorded values checked against the seal's
value clause. (ii) A mutant: a tape that bakes one constant the hypergraph does not list —
acceptance refuses it, at the leaf clause the constant clause rests on. (iii) The axiom
profiles of the seal of the computation, the cone lemma and
the bisimulation theorems, pinned. The worked model's branchless dielectric chain — whose
hypergraph is pinned, whose tape is recorded and whose (H3) is a chain of Evaluates
lemmas — is the instrument the ledger still prices: the match between its two objects is
what the recorder decision fixes.
Lean code for Theorem7.3.9●1 theorem
Associated Lean declarations
-
theoremdefined in PropertyKindCalculus/Tests/Graph/Bisimulation.leancomplete
theorem PropertyKindCalculus.Tests.Bisimulation.bisimulation_witnesses : PropertyKindCalculus.Paradigm.Match.Accepts PropertyKindCalculus.Tests.Bisimulation.g PropertyKindCalculus.Tests.Bisimulation.T PropertyKindCalculus.Tests.Bisimulation.m ∧ ¬PropertyKindCalculus.Paradigm.Match.Accepts PropertyKindCalculus.Tests.Bisimulation.g PropertyKindCalculus.Tests.Bisimulation.Tmut PropertyKindCalculus.Tests.Bisimulation.m
theorem PropertyKindCalculus.Tests.Bisimulation.bisimulation_witnesses : PropertyKindCalculus.Paradigm.Match.Accepts PropertyKindCalculus.Tests.Bisimulation.g PropertyKindCalculus.Tests.Bisimulation.T PropertyKindCalculus.Tests.Bisimulation.m ∧ ¬PropertyKindCalculus.Paradigm.Match.Accepts PropertyKindCalculus.Tests.Bisimulation.g PropertyKindCalculus.Tests.Bisimulation.Tmut PropertyKindCalculus.Tests.Bisimulation.m
**Non-vacuity of the bisimulation**: the matcher accepts the instance and refuses the mutant that bakes an unlisted constant.
(i) and (ii) are kernel-decided theorems over an authored pair, conjoined as the linked
declaration, and a runtime check over the recorded tape; (iii) is #print axioms. Where
(H3) is only a bit-exact runtime gate — the iterated retrieval, the table lookups — an
instance is gated, not proved, and the ledger says so.
What the second capstone changes, and what it leaves. It covers bits and, through R,
kinds: the tape graph's kinds are the hypergraph's, transported, and the matcher checks the
hypergraph's occurrence structure — each family against the operation that realizes it —
against an instrument the harvest does not share. Read as a guarantee about the code: every
occurrence maps to a tape sub-graph realizing its family, every tape path between
observable vertices projects to a hypergraph path, and the kinds transported along R
change only at the image of a declared crossing — so the computation is kind-preserving in
exactly that sense, on a graph that carries no kinds of its own; and speaking of values at
every carrier needs (H3), the denotation bridge, beside it. What remains trusted is
smaller: that the harvest read each node's kind off the kernel-checked term at the right
node, since R transports kinds and does not re-derive them; and the code generator and
toolchain below the tape, which the deployment template lists
as such.