Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Participants: Ben Allen * Stephanie August * Damon Loren Baker * Theo Ellin Ballew * Ivette Bayo Urban * John Bell * Paisley Benaza * Kathi Berens * David Berry * Sayan Bhattacharyya * Christina Boyles * Gregory Bringman * André Brock * Ron Burkey * Evan Buswell * Sarah Ciston * Eileen Clancy * Tara Conley * Krystal Cooper * Ranjodh Dhaliwal * Anthony Di Franco * Craig Dietrich * Jeremy Douglass * Kevin Driscoll * William Dyson * Brandee Easter * Martin Erwig * Schuyler Esprit * Max Feinstein * Todd Furmanski * Geoffrey Gimse * Erin Glass * Rochelle Gold * Catherine Griffiths * Ben Grosser * Fox Harrell * Sydette Harry * Brendan Howell * Nazua Idris * Jessica Johnson * Waliya Yohanna Joseph * Ted Kafala * Dorothy Kim * Corinna Kirsch * Steve Klabnik * Shelly Knotts * Peter Kudenov * Fidelia Lam * Liz Losh * Thor Magnusson * Jim Malazita * Judy Malloy * Zach Mann * Mark Marino * Lauren McCarthy * Irma McClaurin * Patrick McDonnell * Tara McPherson * Todd Milstein * Nick Montfort * Mark Neal * Safiya Noble * Keith O'Hara * David Ogborn * Allison Parrish * Ali Pearl * Gerol Petruzella * Andrew Pilsch * Samuel Pizelo * Jessica Pressman * Helen Pritchard * Daniel Punday * Kristopher Purzycki * Harvey Quamen * Amit Ray * Margaret Rhee * Lisa Rhody * Scott Richmond * Teddy Roland * Jamal Russell * Anastasia Salter * Mark Sample * Evan Schauer * Ari Schlesinger * Mehdy Sedaghat Payam * Ash Smith * Winnie Soon * Glen Southergill * Mel Stanfill * Samara Hayley Steele * Nikki Stevens * Tonia Sutherland * Miriam Sweeney * Ezra Teboul * Daniel Temkin * Dennis Tenen * Marilyn M. Thomas-Houston * Elizabeth Timbs * Giuseppe Torre * Rebecca Uliasz * Annette Vee * Sneha Veeragoudar * Ashleigh Wade * Kurt James Werner * Jacque Wernimont * Zach Whalen * Roger Whitson * Roger Whitson * Michael Widner * Jody Zellen * Kai Zhang
Coordinated by Mark Marino (USC), Jeremy Douglass (UCSB), Catherine Griffiths (USC), Ali Rachel Pearl (USC), and Teddy Roland (UCSB). Sponsored by the Humanities and Critical Code Studies Lab (USC), and the Digital Arts and Humanities Commons (UCSB).

Code, Law, (Smart) Contracts, and Goals vs. Procedures in Praxis

Hi all, I'm new to the field of critical code studies and not sure where what I intended to bring up for discussion fits in, so I'll just share it here in the general category. It's a sprawling topic so I'll try to be as brief as possible and leave the detail to enter into any resulting discussion as needed.

Background

In the law, there exists a distinction in notions of justice between justice arising from the correct procedures having been followed and justice arising from the correct outcome having been reached. The same distinction exists in programming techniques, where most focus on describing the algorithm (procedure) explicitly, and leaving the outcome (goal) implicit, but some techniques (called declarative) invert this, and describe the goal explicitly, and only implicitly derive an algorithm to reach the goal.

In both law and software, the focus on procedure has come at the expense of reaching the desired outcomes. In both, it began with a promise of simplicity - procedures are easier to describe and to prescribe than outcomes, and it is easier to tell whether a procedure has been followed than whether a goal has been reached. But the relationship of any given procedure to the outcome it is intended to reach is tenuous - and the collection of subtle and gross variations of procedure needed to consistently reach a goal in varying circumstances quickly grows impossible to manage.

I believe this phenomenon to be responsible for the explosive growth in complexity observed across law, bureaucracy, and software as they mature, and which brings about their collapse, as described by Tainter in his work, The Collapse of Complex Societies. In my career as a software engineer, I regularly confronted the resulting pathologies, and recoiled from them, taking up a project to embrace the paradigm of programming in terms of explicit goals, and leaving the algorithm for the system to derive implicitly, and I hope that technology might also be a foundation for tools to organize law and society in a similar way, and to help both software projects and social entities avoid the atrophy and collapse that follows from the overgrowth of complexity of procedure.

In concrete terms, this has led me to develop for software the paradigm of information-gain computation, of which the most comprehensive description so far is in this workshop paper. Its key innovation is to develop a general-purpose measure of the progress of a computation in terms of the information gained about a query. It uses this measure of progress to optimize the choices made in evaluating the query. Those choices, in turn, implicitly determine the algorithms used, but that implicit choice remains contextualized so that the choice can continue to be adapted as circumstances change.

The net effect is to relieve humans of the burden of managing the combinatorial explosion of complexity that results from translating goals to procedures, and to keep humans from being the bottleneck in the iterative process of adapting procedures to changing circumstances.

My original technical motivation for developing this was to make smart contracts purely goal-directed, and in turn to open up the use of sophisticated financial tools to people working at the level of sophistication of spreadsheet users running small businesses. (Smart contracts are computer programs that can be used to define financial assets and carry out financial transactions automatically; seminal work on how to formalize them rigorously and elegantly is here. However, the technology applies to all of software, and the concepts, and perhaps the tools as well, may apply to all of law and bureaucracy. My most far-reaching hope is to build out of this an antidote to the kafkaesque horror and waste and human tragedy of living in a society whose institutions are defined as procedural bureacracies, by giving primacy to outcomes, so that procedures can no longer be systematically corrupted and outcomes systematically betrayed.

Proposals For Discussion

I could use a lot more background on humanities work on the kafkaesque horror of bureaucracy, and on the injustice inherent in procedural notions of justice.

I am also curious about general feedback / impressions, and how this line of inquiry might fit in with other work going on in this field.

Comments

  • edited February 4

    @difranco I feel remiss at getting to this so late. I am fascinated by the analogy you draw between programming and law here.

    To understand your approach better and to move us toward some code, I wondered if you could set up the example from your paper and also share the python implementation for our further analysis:

    4.2 Example Preliminaries
    As an elementary example, consider the following code to compute the transitive closure of a graph (phrased in terms of the elementary Prolog programming example about recursively finding ancestors of a person given a set of parent- child relationships):

    ancestor (A, B) :− parent (A, B) . ancestor (A, B) :− parent (A, X) , ancestor (X, B) .
    

    That is, A is an ancestor of B either if A is a parent of B, or if A is a parent of another X and X is an ancestor of B.
    We can use this as the basis of a simple example to test the effects of an adaptive evaluation strategy. To represent the effects of sparsity of the search space, which is the main obstacle that adaptive evaluation is meant to address, we add additional rules that confound the search, like so:

    ancestor (A, B) :− parent (A, B) .
    ancestor (A, B) :− deadend (A, B) . 
    deadend (A, B) :− deadend (A, B,
                                      100000000). 
    deadend (A, B, N) :− N1 i s N − 1 , N > 0
                                    −> deadend (A, B, N1) ;
                                          f a i l . 
    ancestor (A, B) :− parent (A, X) , ancestor (X, B) .
    
    

    Can you explain ths Prolog here briefly?

  • @difranco said:

    In the law, there exists a distinction in notions of justice between justice arising from the correct procedures having been followed and justice arising from the correct outcome having been reached. The same distinction exists in programming techniques, where most focus on describing the algorithm (procedure) explicitly, and leaving the outcome (goal) implicit, but some techniques (called declarative) invert this, and describe the goal explicitly, and only implicitly derive an algorithm to reach the goal.

    In both law and software, the focus on procedure has come at the expense of reaching the desired outcomes.

    I suspect I don't have anything helpful to contribute here, but I wanted to tell you how useful I found this. I'm in the early stages of a project that is exactly about this tension--applying the same procedure in all cases does not in fact produce just outcomes. My context is whose intellectual property is protected and whose isn't, and how it means something different, say, for a Black artist to "steal" rock music for a hip-hop sample than it did for white rock artists to steal Black blues in the first place. Mechanically applying procedures can't account for that, but the law nearly always works by procedure rather than outcome.

    Ultimately it's my hope to do something algorithmic with it--if humans decide Black music is uncreative 20% more often than white music, can we account for that by adding 20% to a creativity score? To technologically reproduce, but also improve upon, human judgments by counteracting the biases built in--by paying attention to outcome at the expense of procedure.

  • One base text you might want to start with that does a bit of connection between source code and legal codes is Lawrence Lessig's Code. Might serve as a foundation text.

    Lessig, Lawrence. Code: And Other Laws of Cyberspace, Version 2.0. 2nd Revised ed. edition, Basic Books, 2006.

Sign In or Register to comment.