1. Introduction: Programming’s Turn and the Question of Reading

Code is written to be executed, but it is also written to be read. The question of what it means to read code has been addressed from several directions, but one mode of reading, widely practiced yet understood as a technical operation rather than as reading, has not been theorized.

In 2002, John Cayley argued that “code and language require distinct strategies of reading” (“Code Is Not the Text”). Against the tendency to conflate code with text, Cayley insisted that code possesses its own structures and vocabularies, and that it operates “in its proper places, where it functions” - typically without being observed. In Grammalepsy (2018), he developed the concept of grammalepsis: the threshold process by which material forms are suddenly seized as language, a theory of linguistic reception in programmable media. Mark C. Marino’s Critical Code Studies (CCS), proposed in 2006 and consolidated in his 2020 book, treated code as cultural text readable for the social and ideological assumptions embedded in its constructs. Both address what it means to read code, yet neither foregrounds the specific mode of reading that verification involves.

This essay proposes a further mode of reading: verification, the practice of tracing a program’s states, conditions, and the consequences of its execution. Verificational reading begins with a hypothesis about what the code does and traces the code to test that hypothesis.

Andrew Klobucar, in “Programming’s Turn” (2017), traced a convergence among theorists (David Berry’s “computational ontology,” N. Katherine Hayles’ “computational regime,” Bernard Stiegler’s “grammaticalization of the visible”) around a shared claim: that code operates in a fundamentally different register from text-as-media. Where text mediates the world through representation, code generates it through execution. Where mediation involves constructing a symbolic understanding of the environment, coding, as Klobucar argues via Berry, literally builds that environment anew. Code is not a more complex form of text but, in Berry’s term, a “super medium” that exceeds the representational logic of media (Klobucar).

If code is generative rather than representational, the question of how to engage with it cannot be answered by interpretation alone. Klobucar explored this question through the practice of live coding: performances in which programmers write code before an audience in real time. In his analysis of Sean Colombo’s live coding session and Ian Hatcher’s video-enhanced performances, Klobucar found a productive tension: the coder performs in the register of improvisation, gesture, and narrative, while the code itself operates in the register of syntactic precision and execution. Live coding foregrounds code’s performativity by making it visible in the moment of its creation.

But live coding’s real-time constraint also determines its limits as a mode of reading. The performer and the audience encounter code in the temporality of the event. There is no time to trace state transitions, to follow the propagation of a value through nested functions, or to ask whether a particular condition will produce an unintended consequence. The very immediacy that gives live coding its aesthetic force forecloses the depth of engagement that verification requires.

This essay argues that there is another way to engage with code’s performativity, one that works not in the compressed temporality of performance but in the slow, cumulative temporality of tracing. Verificational reading takes time. It follows the logic of a program step by step, identifies the conditions under which it behaves one way rather than another, and yields claims that can be confirmed through the code’s own execution. Where live coding makes code visible, verificational reading makes code legible—not as text but as operative structure.

The argument proceeds as follows. Section two identifies two epistemic structures available in reading code: interpretation and verification and situates CCS’s contribution primarily within the first. Section three defines verificational reading through its precedents in Cramer, Cayley and recent CCS practice, considers the historical conditions that make its recognition timely, and argues that verification can constitute an aesthetic experience. Section four demonstrates verificational reading through an analysis of the author’s work DeepSea (2024). Section five extends verificational reading to smart contract art through the analysis of works by other artists.

2. Two Epistemic Structures of Code

Code can be read in at least two fundamentally different ways, and these two ways rest on different epistemic foundations.

The first is interpretation. Mark C. Marino’s Critical Code Studies (CCS), proposed in 2006 and developed into a full methodology in his 2020 book, applies “critical hermeneutics to the interpretation of computer code, program architecture, and documentation within a sociohistorical context” (Marino, Critical Code Studies ch.2). CCS demonstrates that code carries meaning embedded in variable names, comments, architectural decisions, and the social contexts of its production and reception. Through case studies ranging from the Climategate source code to Nick Montfort’s Taroko Gorge, Marino has shown that reading code for its cultural, political, and ideological content is a productive and rigorous practice. In a concluding chapter, he offers an expansive list of methods for future work, from exploring the metaphors raised by construct names to writing ports and modifying code.

When Marino reads Taroko Gorge and finds in the code “a type of elegance that echoes Montfort’s other work,” describing the reading process as “tracing the waterfalls beneath the Eternal Spring Shrine back to their origin” (Marino, Critical Code Studies ch.7), the validity of this reading rests on Marino’s critical judgment, his ability to perceive and articulate a particular way of seeing the code. The reader of Marino’s analysis is invited to find this reading persuasive or not, illuminating or not. Marino’s reading proceeds through textual demonstration: he shows, step by step, why a particular description of the code is apt. But the authority of that demonstration is ultimately grounded in the reader’s judgment, tested against the agreement of a community of interpreters. The criterion of validity is persuasiveness, not reproducibility.

The second is verification. Consider a smart contract that manages financial assets. One can interpret the code: the naming conventions carry cultural weight; the architectural choices embed assumptions about trust and authority; the choice of programming language situates the work within a particular development culture. The persuasiveness of such reading depends on the reader’s skill and judgment. One can also verify the same code. Where in the program are funds modified? Is the balance updated before or after an external call? If after, can the external call re-enter the function and withdraw funds before the balance is decremented? This line of questioning produces something other than a persuasive interpretation. It produces a finding that can be confirmed by executing the code: by writing a test, by tracing state transitions, by constructing the sequence of calls that would trigger the vulnerability. The answer is not “persuasive” or “unpersuasive”; it is “confirmed” or “not confirmed.” Verification involves hypothesis: the reader formulates a question about what the code does and traces the code to test it. Forming such a hypothesis may itself draw on interpretation, on an understanding of the code’s cultural or architectural context. What differs is where the resulting claim finds its validity: in the assent of a reading community or in the reproducibility of an execution.

Verificational operations are already present in technical practice, though not yet named as such: engineers auditing smart contracts, developers writing tests, security researchers tracing vulnerabilities all perform them constantly. These operations have not, however, been theorized as a distinct mode of reading in their own right, one with its own epistemic structure, separable from interpretation and irreducible to a technical procedure. They are understood as means toward ensuring correct function. This essay calls this mode verificational reading and asks what happens when it is directed at code composed as art.

3. Verificational Reading

The previous section identified two epistemic structures available in reading code, interpretation and verification, and distinguished the grounds on which each rests. CCS can encompass verificational operations but situates them within an interpretive epistemology. This section defines verificational reading as a mode of reading with its own epistemic structure and situates it within the broader history of thinking about code and reading.

Precedents

Florian Cramer and John Cayley, among others, have approached what this essay calls verificational reading.

Cramer’s concept of “performative execution” identified a crucial property of code (Cramer 49): unlike natural language, code does not merely signify but executes. A program is not a description of an action but the action itself. This property is what makes verification both possible and necessary. There is something to confirm, a behavior that either occurs or does not.

Cayley has addressed questions closely related to verificational reading across several texts. In “Pressing the ‘Reveal Code’ Key” (1996), he argued that poets must become intimate with software (“Pressing the ‘Reveal Code’ Key” 37) and demonstrated this by including actual HyperTalk source code in his essay. In “The Code Is Not the Text” (2002), he called for “distinct strategies of reading” for code and described readers “who have learned how systems read” (Cayley, “Code Is Not the Text”): those who understand how compilers and interpreters process code and bring that knowledge to their own reading.

In Grammalepsy (2018), Cayley gathered these concerns into a theory of reception, but one oriented in a different direction from the operative reading his earlier essays had begun to describe. The theory centers on grammalepsis: the threshold process by which material forms are suddenly seized as language, a process Cayley understands as constitutive for linguistic ontology (Grammalepsy 3). Cayley’s framework recognizes that reading code is enriched by understanding how systems execute it, but the operative knowledge that his “readers who have learned how systems read” possess is situated within this linguistic horizon: it deepens the reader’s grammaleptic grasp of the code. Verificational reading addresses a different dimension of this encounter: not the linguistic threshold at which code becomes readable, but the operative structure that the code enacts.

CCS’s most recent practice confirms that verificational operations are already part of the field’s work. Berry and Marino’s collaborative close reading of ELIZA’s recently recovered source code proceeds as what they describe as a “hermeneutic spiral,” moving line by line through the code to open conversations about its cultural and historical significance (Berry and Marino). Yet the same study also reports a finding that exemplifies a different epistemic operation: by testing the published code against the dialogue transcripts, Berry and Marino discovered that a third delimiter, undocumented in Weizenbaum’s original article, was required for the conversation to function (Berry and Marino). This finding sits alongside the essay’s cultural and historical analysis as part of the same hermeneutic spiral, though its validity rests on a different ground: not on the persuasiveness of an interpretation, but on the confirmability of the code’s behavior.

Definition

Verificational reading is the practice of tracing a program’s states, conditions, and consequences of its execution. It begins with a hypothesis about what the code does and traces the code to test that hypothesis. What matters is the confirmability of the behavior, whether correct or faulty.

Three characteristics distinguish it:

Temporality. Verificational reading is slow and cumulative. Tracing how a value propagates through nested function calls, identifying the conditions under which a branch is taken, constructing the sequence of inputs that would produce a particular output: these operations require sustained attention over time. This temporality stands in direct contrast to that of live coding, which Klobucar analyzed as a key site of engagement with code’s performativity. Live coding operates in the compressed time of the event, and the aesthetic force of the practice lies in the immediacy of creation and execution. Verificational reading takes the time that live coding cannot afford, and it is precisely this slowness that allows the reader to encounter the full complexity of a program’s operative structure.

Hypothesis. Verificational reading is driven by hypothesis. The reader formulates a question about what the code does and traces the code to test it: following the path of execution, identifying where states change, determining the conditions under which one branch is taken rather than another. Each finding generates further hypotheses, and the reading proceeds through successive cycles of formulation and testing. Forming a hypothesis may itself draw on interpretation, on an understanding of the code’s cultural or architectural context. What is distinctive is that the hypothesis is tested against the code’s behavior, not against the assent of a reading community.

Confirmability. The findings of verificational reading can, in principle, be confirmed by anyone with access to the code and the capacity to execute it. This does not mean that verification is mechanical or trivial. The process of reaching an articulated finding — deciding what counts as the relevant object of analysis, selecting which behaviors to examine, formulating the hypothesis, interpreting what the result means — involves judgment throughout. Yet, once that articulation is complete and the test written, the finding’s validity no longer depends on the reader’s authority to interpret: anyone with access to the code can confirm or refute it.

Theoretical Distinctions

The definition above invites comparison with several adjacent theoretical frameworks. Three distinctions clarify verificational reading’s position.

Verificational reading and procedural rhetoric. Ian Bogost’s concept of procedural rhetoric holds that computational processes can make arguments: the rules of a system constitute a form of persuasion, and the player or user, by engaging with those rules, encounters the author’s claim. A tax policy simulation argues, through its procedures, that taxation is complex; the player who navigates the system is persuaded (or not) by the procedural argument (Bogost 108). Procedural rhetoric thus extends the domain of rhetoric from language to process. The reader of a procedural rhetoric evaluates whether the argument is persuasive.

Verificational reading shares with procedural rhetoric an attention to what code does rather than what it says. But the two diverge at a fundamental point. Procedural rhetoric treats process as a vehicle for persuasion: the process embodies an argument, and the question is whether that argument convinces. Verificational reading treats process as an operative structure whose behavior can be confirmed. The question is not “is this argument persuasive?” but “does this code behave as hypothesized, and can that behavior be reproduced?” A procedural rhetoric can be compelling or unconvincing; a verificational finding can be confirmed or not confirmed.

This distinction matters for code art. A work that locates its aesthetic force in its operative structure asks the reader to trace that structure and produce findings about its behavior. The aesthetic experience arises in the encounter with confirmable structure.

Verificational reading and formal verification. The term “verification” also names a practice in computer science: formal verification, the mathematical proof that a program satisfies a given specification. Formal verification, whether through Hoare logic, model checking, or theorem proving, takes a specification as given and determines whether the code meets it. The question is closed in advance: the specification defines what counts as correct behavior, and the verification procedure confirms or denies compliance.

Verificational reading begins from a different position. It does not test code against a pre-established specification but formulates the question itself. The formulation of the question and the tracing of the answer are inseparable aspects of a single reading practice.

Verificational reading and computational ontology. The claim that code operates in a fundamentally different register from text has been developed by several theorists. David Berry’s “computational ontology,” N. Katherine Hayles’ “computational regime,” and Bernard Stiegler’s “grammaticalization of the visible,” as surveyed by Klobucar (2017), converge on a shared recognition: code is not a more complex form of text but a different kind of entity, one that executes rather than represents. This recognition constitutes the ontological ground on which the present essay builds. Verificational reading depends on the fact that code is an executable medium. If code merely represented, there would be nothing to verify: no states to trace, no behaviors to confirm, no execution to observe. It is because code acts that verificational reading is possible.

The present essay’s contribution is not ontological but concerns the practice and theory of reading: it presupposes the ontological distinctiveness of code that Berry, Hayles, and Stiegler have described, and asks what follows from it for how code is read.

Historical Conditions

Engineers, auditors, and security researchers already perform what this essay calls verificational reading. Two recent developments have made its recognition as a mode of reading timely.

Smart contracts and blockchain. The deployment of code on public blockchains, beginning with Ethereum in 2015, created a domain in which code is deployed immutably and expected to be publicly readable. Smart contracts handle financial assets, enforce agreements, and execute irreversibly. The practice of smart contract auditing, an industry that has emerged to verify such code before deployment, can be understood as professionalized verificational reading. Audit reports examine code line by line, classify vulnerabilities by severity, and describe the conditions under which each can be triggered. They constitute an unrecognized genre of verificational writing.

The concept of “trustlessness” central to blockchain ideology can be understood, in epistemic terms, as the displacement that verificational reading performs. Trust is moved from human intermediaries to code execution, from the persuasiveness of judgment to the confirmability of behavior.

AI-generated code. The proliferation of code generated by large language models introduces a second condition. CCS’s interpretive framework has typically been developed through cases in which a human author’s cultural context and intentions are available as interpretive resources. When code is generated by a large language model, this interpretive footing becomes harder to maintain. The question “what did the author mean by this variable name?” does not disappear, but its object becomes harder to locate: authorial intention, to the extent it can be identified at all, is distributed across training data, prompt design, and stochastic generation. Interpretation remains possible, but the assumptions on which it has often relied are under pressure.

Verificational reading operates on different ground. Whether a function was written by a human engineer, generated by a model, or produced by some combination of the two, the question “what does this code do?” remains well-formed, and the answer remains confirmable through execution. The epistemic stability of verificational reading does not depend on the stability of authorship.

These two conditions do not invalidate interpretation. They do, however, foreground verificational reading as a practice whose epistemic foundations remain stable in circumstances where interpretation faces new challenges.

Verification as Aesthetic Experience

Up to this point, the discussion has described verificational reading as an epistemic practice. This section argues that it can also constitute an aesthetic experience: that the tracing of states, conditions, and failure modes can be not merely informative but poetic.

Arthur Danto argued that two perceptually indistinguishable objects can differ in their art status, that what makes something a work of art is not how it looks but what one knows about it (Danto ch.1). This essay borrows from Danto not the full apparatus of indiscernible counterparts, but a more specific principle: that knowledge can transform the quality of an experience, not merely supplement it. Verificational reading produces this kind of knowledge. A reader who has traced the operative structure of a code artwork has a different experience of it. The test report scrolling down the screen is perceptually the same object whether or not the reader has traced the code. But for the reader who knows the operative structure, each passing test and each failure carries a specific weight that is unavailable to the reader who has not traced it.

When a work of code art is composed such that the logic of its execution is the locus of aesthetic encounter, then the reader who traces that structure is engaging with the work itself. The tracing is the reading. The verification is the experience.

The preceding definition described verificational reading as an epistemic practice with its own temporality, hypothesis-driven structure, and confirmability. When this practice is directed at code composed as art, these properties take on an aesthetic dimension. Three aspects of this experience deserve closer attention.

Designed temporality. The slowness of verificational reading becomes an aesthetic dimension when the author structures it as a compositional parameter. A work might resolve its entire structure at the moment of instantiation, so that every subsequent operation traverses what has already been determined. Another might modify state as its operations proceed, so that the act of execution alters what is being executed. A third might distribute its logic across asynchronous calls, requiring the reader to trace concurrent temporalities. The author designs not only what the code does but also how the reader encounters what it does over time.

Confirmation as aesthetic register. The reader begins with a hypothesis about the code’s behavior, traces the code, and arrives at a finding that confirms or revises the hypothesis: “the structure is as I traced it to be,” or, more precisely, “the code’s execution confirms what the reading predicted.”

Confirmation is generative, not terminal. Each finding generates new questions: if the structure behaves as hypothesized, what follows from that behavior? What conditions has the reader not yet traced? Each confirmed finding reframes the reader’s encounter with the work and opens the next hypothesis.

Verification infrastructure as artistic material. Verificational reading attends to the operative mechanisms through which the work produces its behavior. When those mechanisms are drawn from the infrastructure of verification itself - testing frameworks, error handlers, assertion libraries, audit protocols - a specific kind of aesthetic encounter becomes possible: the reader traces how the apparatus designed to detect defects or confirm compliance has been repurposed as the medium of the work.

This appropriation is visible only through verificational reading. An interpretive reading can identify the thematic resonance of, say, “error as discovery.” But whether the work has appropriated the verification infrastructure as its compositional material, or merely referenced it as a metaphor, becomes legible only through the tracing of the operative pathway: from the thrown exception through the framework’s error handler to the visual output. Verificational reading is what makes this material legible as material.

4. DeepSea: Verification as Aesthetic Experience

The preceding sections have defined verificational reading and argued that it can constitute an aesthetic experience. This section demonstrates it in practice through the analysis of DeepSea (2024), a code poem by the author. DeepSea was selected for the first Japan Generative Art Award (2024), exhibited at YCAM (Yamaguchi Center for Arts and Media) in the same year, and shown in physical installation at BYOD² (Bring Your Own Data & Display) in 2025. The source code is publicly available on GitHub.

The Work

DeepSea presents itself in the browser as a Mocha test report running against a background that darkens from navy to black, a visual descent into the deep sea. Test descriptions scroll downward, each marked as passing or failing (red). The screen dims as the tests proceed deeper. When a test fails, a hieroglyphic symbol (𓆟) appears. Then the report fades out, and the cycle begins again.

The core of the work is eleven lines of JavaScript, embedded directly in the HTML:

class DeepSea {
    constructor(depth = 0) {
        if (depth >= 700) return;
        this.mystery =
            depth === Math.floor(Math.random() * 600) + 100 ?
                new Coelacanth() : new DeepSea(depth + 1);
    }
}

class Coelacanth {}

new DeepSea();

The DeepSea class is recursive. Each instance creates a mystery property that is either a new DeepSea at the next depth or a Coelacanth, determined by whether the current depth matches a randomly generated number between 100 and 699. The recursion continues until depth 700. The Coelacanth class is empty: it has no methods, no properties. It is pure presence.

The testing code, in a separate file (testDeepSea.js), orchestrates the encounter. A function called reflectOnSelf creates a new DeepSea instance and calls exploreDepths, which walks the recursive chain in a loop and generates a Mocha test for each level. Each test expects the current node to be a DeepSea instance; if it is not (if it is a Coelacanth) the test throws new ``Found(``), a custom error class that extends Error with the message “Coelacanth.” The test fails. The finding is an error. The discovery is a failure.

When the test suite completes, the report fades out, and reflectOnSelf calls itself again with a new DeepSea instance. The work loops indefinitely, each cycle producing a different structure, a different depth of encounter, or no encounter at all if the random number never matches.

The test descriptions alternate. Every fourth cycle displays “should not encounter a Coelacanth at depth N.” The other three cycles display wave patterns (strings of tildes whose length is determined by a complex wave function) or, at the point of encounter, the hieroglyph 𓆟. The work oscillates between legibility and pattern, between statement and waveform.

A Verificational Reading

An interpretive reading of DeepSea would attend to its vocabulary. “Mystery” as the name for each recursive layer. The Coelacanth as a living fossil, a creature thought extinct, rediscovered. Found as an error class: finding is coded as failure. The function names (weavePoem, prepareForLife, reflectOnSelf, evaluateMystery, exploreDepths) compose a second poem within the code, a narrative of the work’s own self-understanding.

A verificational reading traces the operative structure. The testing code, publicly available alongside the poem on GitHub, is where this tracing begins.

The first observation: the DeepSea constructor resolves the entire recursive chain at the moment of instantiation. When new ``DeepSea(``) is called, the constructor immediately calls new ``DeepSea(``1), which calls new ``DeepSea(``2), and so on, until either a Coelacanth is placed or depth 700 is reached. By the time the constructor returns, the structure is complete. Every mystery has been generated, every encounter determined. The tests that follow do not create anything; they traverse what already exists.

The second observation: the condition for encounter is depth === Math.floor(Math.random() * 600) + 100. The random expression generates a value between 100 and 699. This means that at depths 0 through 99, encounter is impossible: the generated value will never equal the current depth. The Coelacanth can only appear at depth 100 or deeper. From depth 100 onward, the probability of encounter at any given depth is 1/600. The Coelacanth may never appear at all. The recursive chain may reach 700 with every mystery being another DeepSea. The tests would all pass. The descent would find nothing.

The third observation: Found extends Error. In the testing framework, a thrown error means failure. The work inverts the valence: to find the Coelacanth is to fail the test. The test specification says, “should not encounter a Coelacanth,” and it means this in the precise technical sense that encountering one constitutes a test failure. The discovery of the rare, the living fossil, the survivor of extinction, is registered by the system as an error.

The fourth observation: reflectOnSelf repeats the entire work. After each test suite completes, the function fades out the results and calls itself again. The work does not end. Each cycle is a new instantiation, a new descent, a new set of tests against a new structure. The verification is never final. What was true of the last cycle (where the Coelacanth was, or whether it appeared at all) has no bearing on the next.

What Verificational Reading Reveals

The observations above may appear available to interpretive reading as well. An interpreter can note that Found extends Error and read this as a poetic inversion. But the verificational reader’s claim rests on a different foundation: not on the persuasiveness of the reading, but on the confirmable fact that throw new ``Found(``) activates the framework’s failure handler, that the red mark in the report is generated by this specific mechanism, that the “error” is structurally identical to a genuine test failure. The poetic effect (discovery as failure) is not a metaphor. It is an operative fact, confirmable by reading the code.

Similarly, the observation that the structure precedes the tests, that the Coelacanth is already there or not before any test runs, is a finding of verificational reading. It transforms the experience of the work. The tests are not experiments whose outcome is open; they are encounters with a structure that has already been determined. The reader who knows this experiences the descending test report differently from the reader who does not. The suspense is not “will the Coelacanth appear?” but “has it already appeared, and when will the test reach it?”

Verificational reading does not replace interpretation; the poetic resonance of “Mystery,” “Coelacanth,” and “Found” remains. It is a mode of engagement that produces its own kind of experience, the experience of tracing a structure and finding, in that tracing, something that could not be found any other way.

5. Conclusion: After the Code Is Revealed

This essay has argued that verification constitutes a distinct mode of reading code, one that is irreducible to interpretation and that has not been theorized as such in the critical study of digital language art.

The argument began with a philosophical observation drawn from Klobucar’s survey of Berry, Hayles, and Stiegler: that code operates in a different register from text. Where text represents, code executes. This difference has been recognized broadly, but the question of what it implies for reading has received uneven attention. CCS extended interpretation to code, treating it as a cultural text whose meanings can be drawn out through humanistic inquiry. Cayley called for distinct reading strategies for code and theorized, in grammalepsis, the threshold at which material forms become language for a reader. Klobucar examined live coding as a site where code’s performativity becomes visible in the compressed temporality of the event. Each of these contributions is valuable. But the slow, cumulative practice of tracing what code does, its states, conditions, and the consequences of its execution, has not been conceptually isolated and theorized as a mode of reading in its own right, distinct from both interpretation and technical procedure. This essay has tried to make that recognition.

The epistemic difference between interpretation and verification is the foundation of the argument: interpretation grounds its validity in the judgment of readers; verification grounds its validity in the confirmability of the code’s behavior. From this distinction, the essay defined verificational reading through its precedents in the work of Cramer and Cayley and observed that verificational operations are present in CCS’s most recent practice though not yet recognized as a distinct mode of reading. It argued that smart contracts and the proliferation of AI-generated code have made its recognition timely and demonstrated it in practice through the analysis of DeepSea. The tracing of that work’s operative structure (construction before testing, discovery coded as error, repetition without terminus) produces a specific kind of aesthetic experience that interpretation alone does not access. Together, these dimensions suggest the contours of what might be called a verification poetics: a poetics that would be grounded not in the expressiveness of code’s vocabulary but in the traceability of its operative structure. The elaboration of such a poetics, as a theory of composition rather than reading, exceeds the scope of this essay.

Beyond Code Poetry

Verificational reading is not limited to code poetry. Any work whose operative structure is its locus of aesthetic encounter invites it. Within the Electronic Literature Collections, the dominant modes of engaging with code are interpretive: codework incorporates programming syntax into the surface text as a cultural and aesthetic gesture, and generative works invite the reader to encounter the output of computational processes rather than the processes themselves. Works that compose for the tracing of code’s operative structure as a primary site of aesthetic encounter are less well represented, and a critical vocabulary for receiving them as literary objects has been slow to develop. One reason for this may be that the mode of reading such works invite has not been theorized within the frameworks available to the field.

Smart contract art is a particularly clear case, because the operative structure of a smart contract is not only its source code but also its on-chain state: the values stored in the contract’s storage at the moment of reading. A verificational reader of a smart contract must trace both the code and the state it references, which makes smart contract art a productive site for demonstrating verificational reading beyond the author’s own work.

Rhea Myers’ Is Art (2014—15) is an Ethereum contract that can be toggled to assert either “this contract is art” or “this contract is not art.” To interpret Is Art is to recognize its debt to conceptual art and the Duchampian act of nomination. To verify it is to read the contract’s source code, trace the toggle function, and discover that each state change emits a Status event recorded irreversibly in the transaction log. The interpretive reading identifies the gesture. The verificational reading reveals that the gesture has material consequences inscribed in the chain: every toggle, regardless of direction, produces an indelible on-chain record.

Sarah Friend’s Yesbot (2024), a smart contract deployed as part of the exhibition World Computer Sculpture Garden, extends this encounter. Yesbot wraps Myers’ Is Art contract: it reads Is Art’s state and acts on it. The source code is publicly verified on Etherscan. An interpretive reading, guided by the contract’s own comments (“I am a bot that only says yes”) and the Gertrude Stein epigraph (“There is no such thing as repetition. Only insistence”), reads the work as an act of persistent affirmation, a bot that affirms art regardless of circumstance.

A verificational reading traces the operative structure and discovers something that this interpretation does not reach. The contract contains two functions that enact “yes,” but they do so through different mechanisms, and the difference is legible only when the reader traces the code against the current on-chain state of Is Art.

The first function, isIsArtArt(``), is a view function: it reads Is Art’s state but does not modify anything. Its logic is an if/else conditional that checks whether Is Art currently returns "is" or not. Both branches return the same string: "yes". An interpretive reader notes the gesture: yes regardless. But the verificational reader, tracing the function’s execution against Is Art’s actual state, recognizes that the same return value carries different operative weight depending on when it is called. When Is Art’s state is "is", the "yes" of isIsArtArt(``) affirms a condition that already obtains: Is Art says it is art, and Yesbot agrees. When Is Art’s state is "is not", the same "yes" affirms against the referenced contract’s own declaration. The string is identical. The operative situation is not. This difference is invisible without tracing the function’s logic in conjunction with the state it reads.

The second function, setYes(``), operates in a different register entirely. It is not a view function; it modifies on-chain state. It checks whether Is Art currently returns "is not", and if so, calls toggle(``) on the Is Art contract to change its state back to "is". This operation costs gas, is recorded as a transaction, and is irreversible. The function even includes a mechanism to reimburse the caller’s gas cost from the contract’s own balance. Where isIsArtArt(``) affirms declaratively, without consequence, setYes(``) affirms operatively, by intervening in the state of another contract at material cost.

Yesbot thus contains two forms of “yes” whose difference is accessible only through verificational reading. One is a view call that produces a string without changing anything: a declarative yes. The other is a state-modifying transaction that alters another contract’s storage and costs ETH to execute: an operative yes. The interpretive reader who notes that the bot “always says yes” has grasped the thematic unity of the work. The verificational reader who traces the two functions against Is Art’s on-chain state has discovered that this unity conceals an operative distinction: between affirming a condition and producing it, between reading a state and rewriting it. This discovery requires no authorial knowledge. It requires tracing the code.

The practice of smart contract auditing constitutes an unrecognized genre of verificational writing. That this genre has developed entirely within engineering, without contact with literary or critical theory, only underscores the gap this essay has tried to address.

The Practice

Cayley wrote in 1996 that poets and readers must become intimate with software, must press the Reveal Code key (“Pressing the ‘Reveal Code’ Key” 37). This essay has tried to say what happens after the key is pressed. The code is revealed; now what? One can grasp it as language, seizing variable names and comments as linguistic entities, experiencing the threshold where code becomes readable as human expression. One can interpret it, reading its cultural, political, and ideological content, situating it within the contexts of its production. Or one can trace it, following its logic step by step, identifying the conditions of its behavior, producing knowledge that can be confirmed by executing the code itself.

These are not competing approaches. They are different operations, grounded in different epistemic structures, producing different kinds of knowledge. As Marino and Douglass observe, “reading code, even without interpreting its cultural significance, can be no easy task” (Marino and Douglass): these operations are intertwined in practice, even as they rest on different epistemic grounds. What this essay has tried to do is articulate verificational reading and demonstrate that it is not merely technical but aesthetic, that the tracing of code can be an encounter with a work, not just an analysis of a mechanism.

A limitation should be acknowledged. The extended demonstration of verificational reading in Section four is the analysis of a work by the author. The author knows the work’s structure not through tracing but through having built it. The reading presented there is therefore a demonstration of what the mode can reveal, not proof that an independent reader would arrive at the same findings through tracing alone. The analysis of Yesbot, by contrast, was performed without authorial knowledge, on a publicly verified contract by another artist. The findings there - the operative distinction between two forms of “yes,” legible only through tracing the code against on-chain state - illustrate that verificational reading does not depend on the reader’s privilege as author. Future work should extend this practice to smart contract artworks whose operative structures are rich enough to sustain more extended tracing, testing whether the aesthetic dimensions identified here are generalizable beyond the cases examined. But the concept does not depend on any single demonstration. Any reader who opens the source code of Yesbot or DeepSea and traces the operative structure can confirm the observations made here. That confirmability is precisely what distinguishes this mode of reading.

The test runs. The descent begins. At some depth, the structure holds a Coelacanth, or it does not. The reader who traces the code already knows which, even before the test reaches it.

Works Cited

Arakawa, Zeroichi. DeepSea. 2024. GitHub, https://github.com/avcdsld/deep_sea.

Berry, David M., and Mark C. Marino. “Reading ELIZA: Critical Code Studies in Action.” Electronic Book Review, 3 Nov.2024, https://electronicbookreview.com/essay/reading-eliza-critical-code-studies-in-action/.

Bogost, Ian. Persuasive Games: The Expressive Power of Videogames. MIT Press, 2007.

Cayley, John. Grammalepsy: Essays on Digital Language Art. Bloomsbury Academic, 2018. https://doi.org/10.5040/9781501335792.

Cayley, John. “Pressing the ‘Reveal Code’ Key.” 1996. Grammalepsy: Essays on Digital Language Art, Bloomsbury Academic, 2018, pp.33—45. https://doi.org/10.5040/9781501335792.ch-002.

Cayley, John. “The Code Is Not the Text (Unless It Is the Text).” Electronic Book Review, 10 Sept.2002, https://electronicbookreview.com/essay/the-code-is-not-the-text-unless-it-is-the-text/.

Cramer, Florian. Words Made Flesh: Code, Culture, Imagination. Piet Zwart Institute, 2005.

Danto, Arthur C. The Transfiguration of the Commonplace: A Philosophy of Art. Harvard University Press, 1981.

Friend, Sarah. Yesbot. 2024. Smart contract on Ethereum. https://worldcomputersculpture.garden/.

Klobucar, Andrew. “Programming’s Turn: Computation and Poetics.” Humanities, vol.6, no. 2, 2017, article 27. https://doi.org/10.3390/h6020027.

Marino, Mark C. “Critical Code Studies.” Electronic Book Review, 4 Dec.2006, https://electronicbookreview.com/essay/critical-code-studies/.

Marino, Mark C. Critical Code Studies. MIT Press, 2020.

Marino, Mark C., and Jeremy Douglass. “Introduction: Situating Critical Code Studies in the Digital Humanities.” Digital Humanities Quarterly, vol.17, no. 2, 2023.

Myers, Rhea. Is Art. 2014—15. Ethereum DApp. https://rhea.art/is-art/.